I'd like to know whats the difference when creating new symfony project with new symfony installer that has appeared last time and old-way composer.
I've installed latest version of symfony (2.6.1) with both, and result was different, for example when I install symfony with composer, i get .gitignore file.
When I install with new symfony installer script, gitignore is missing.
Here is amount of catalogs and files in fresh project:
symfony installer: 1498 directories, 7136 files
symfony installer + composer update: 1571 directories, 7749 files
composer create-project: 1615 directories, 7905 files
I suppose I'll stick to old way - composer, since new installer seems to be bugged or at least not complete yet, however I'd like to understand more on this topic, whats the difference, is it safe to use new installer etc?
As Leggendario already explained, the installer downloads the dist files from the website (a .tar.gz or .zip file). This speeds up the installation process quite a bit.
However, when building the dist files, symfony.com uses a custom build script which removes some files and changes some things. On the other hand, composer simply downloads the repository for you.
The main differences:
Composer downloads the latest dependencies (as Leggendario pointed out), while the build script contains the latest files at the moment of building.
Composer uses the dev versions and thus uses git clone to download the packages. The build script uses only stable packages, which will make Composer use the dist version. Some packages remove test and doc files from their dist files.
Composer contains all project related information, like a .gitignore. The build script previously assumed the person installing it didn't have git, so removed this file and other git related files like the .gitkeep files in app/cache and app/logs.
I any case, both the installer and composer always give you a working version of the Symfony Standard Edition.
At last, the build script was changed now the installer became the official way of installing. It'll now contain the git related files. On the other hand, it'll not contain the LICENSE file, UPGRADE-*.md files and README.md file. So in the end, we can say that the one installed by the installer is more usable, as it removes useless files.
Symfony2 Installer will downloaded it from the web site ( in this case: http://symfony.com/download?v=Symfony_Standard_Vendors_2.6.1.zip ).
To see the differences between symfony installer and the classic composer create-project is enough to take a look at both composer.lock: https://www.diffchecker.com/oig86oki
On the left the composer.lock generated after composer create-project, on the right symfony installer. It was obvious to everyone that Symfony2 downloaded from an archive could not have the lastest packages. So, do the update with composer update.
Again, on the left the composer.lock of composer create-project, on the right the new composer.lock after the update: https://www.diffchecker.com/lj5j2eap
As we expected. But in the vendor dir there are not the same number of file. Some folders are not there. Some folders with functional tests are not downloaded with symfony installer. You need to force composer to update all packages, or reinstall them.
Did you update installer as well with :
symfony self-update
or in windows :
php symfony.phar self-update
As stated here ?
That's perhaps one part of the answer.
Among differences, the installer seems to deal better with different symfony versions.
Related
I have a hard time figuring this out; I am also puzzled of the connection - if any - with the create-project command.
As far as I can tell, the only difference between install and create-project is the execution of post-root-package-install and post-create-project-cmd hooks...
Can someone shed some more light on this?
My goal is to set up a composer infrastructure where I run create-project and this sets up a project skeleton (creates and sets directory permissions, creates default configuration files, creates blank data stores)
What exactly is the difference between project and library types in composer?
Practically, there is none. It doesn't affect how composer gets executed. You can use both install and create-project with both types of package types.
This metadata is meant to inform plugins, IDE, or even packagist.org when parsing composer.json, but on a vainilla installation, there is no practical difference in using one or the other.
(Docs on package types)
As far as I can tell, the only difference between install and create-project is the execution of post-root-package-install and post-create-project-cmd hooks.
The docs are your friends:
You can use Composer to create new projects from an existing package. This is the equivalent of doing a git clone/svn checkout followed by a composer install of the vendors.
Any time you do create-project, install is executed as well. Which means that the install hooks are executed as well.
First it clones the whole package via the appropriate CVS (git, usually), and then immediately executes composer install. By default, it removes CVS information (e.g. the .git directory), unless one uses the --keep-vcs option.
create-project is useful to bootstrap applications, so the app's directory is setup beyond what downloading composer`s dependencies would do. You can create a skeleton directory structure, etc.
Usually one would have a package proper (that could be required into an application), and a "application-skeleton" package, that would include the directory structure and would depend on the original package.
I'm posting a more succint answer to my questions, based on experimentation:
What is the difference between project and library types?
Absolutely none as far as composer is concerned. Some plugins might implement logic to treat the two package types differently though.
How does that relate to require, install, create-project commands?
In no way whatsoever. The project in package type has nothing to do with project in create-project.
How does create-project work?
Let's say we are talking about a single <package>. We have 2 workflows:
composer init <project_path> && composer require <package>
composer create-project <package> <project_path>
The first workflow will create a blank root package and add <package> as a requirement to it.
The second workflow will "clone" <package> into <project_path> as the root package.
NB: If you are working with local path type repos for development, create-project will actually create <project_path> as a symlink to <package>'s source dir. This is the default behavior of path repos, and probably a miss for composer in the need to treat create-project differently. This can create a heap of confusion (as you might be inadvertently changing and adding to <package>s sources while thinking you are just editing project_path). So for local development and testing, you are better off with cp -A rather than composer create-project.
I'm working on a project based on PHP7 and Laravel. Unfortunately, there was a problem with dependencies and package versions.
I guessed that the previous developer working on the project started updating packages by calling
composer update
on his local dev environment.
Therefore, a new composer.lock file has been generated and everything has been pushed to the production server - however, the composer update command has not been called on the production...
There is a problem with the incompatibility of the PHP version and other errors in dependencies.
This is a very large project and I wouldn't like to migrate now to higher versions on the production server.
I am currently preparing a development environment and I care about maintaining the maximum compatibility of all package versions with what is on production.
By calling:
composer install
on local environment, I'm receiving a series of errors related to the incompatibility of the package versions.
Is there any way to regenerate / restore composer.json and composer.lock based on what is currently installed on the production server? Unfortunately, at this moment composer.lock on production doesn't completely reflect the current state of actually installed versions.
What is a safe and good way to recreate locally a cloned project from a repository on a production server - and maintain full compatibility of all package versions, the correct form of composer.json and composer.lock?
Thanks in advance for your help!
To run composer update and composer install
You can run with this code
composer install --ignore-platform-reqs
Or for update
composer update --ignore-platform-reqs
I found https://www.wuhaiqiao.com/2020/11/24/329.html
No, there is no way to recreate composer.json file based on what is already installed in /vendor. You can look for /vendor/composer/installed.json file as a reference for installed versions of all packages.
What you need to do in this case is:
Make sure your local environment is exactly the same as your production one. You can fake it if needed in your composer.json too by using platform configuration.
Your composer.lock file is of no use. Get /vendor/composer/installed.json file from your production. Delete your /vendor folder.
Run composer install. Write down all packages that have issues and check provided solutions by Composer.
Start downgrading the versions in your composer.json for packages that have issues based to the solutions provided by Composer. Be sure to look into those packages yourself - developers aren't always very strict with the way they maintain dependencies and versioning of their packages. You can always just take package version from production's /vendor/composer/installed.json and place that specific version in your composer.json.
Repeat steps 3-4 until you can finally generate new composer.lock file. Make sure your composer.json and composer.lock files are tracked by your VCS and fixate the changes.
When creating sites using a framework like Silverstripe I often want to use helper modules like gridfieldextensions and lumberjack.
I therefore use composer require to add the dependencies.
However when I follow my regular development work flow and use git add -A to add the module to the repo rather than the code being added to the repo I get a reference to it.
This causes problems when I then try to clone the site elsewhere (using Jenkins or another developer). The git clone or git pull leaves an empty directory.
I solve this by deleting the .git dir of the module and adding all the files.
Is there a better way to do this? Is using git submodule an option?
Somewhere i found a good .gitignore file that ignores everything and i have to tell it to include the custom modules for my project. It's like:
# ignore everything...
/*
# ...but
!/.htaccess
!/.gitignore
!/composer.json
!/composer.lock
!/Capfile
!/Gemfile
!/favicon.ico
!/touch-icon-*
!/mysite
!/some-module
#...other modules
# theme stuff
!/themes/
**/.sass-cache
**/node_modules
!**/node_modules/_manifest_exclude
#no assets in general, but /assets/.htaccess
!/assets
/assets/*
!assets/.htaccess
As FinBoWa already said you need the composer.json and composer.lock file in your project and running
composer install
on another machine it'll install the packages in the versions saved in the composer.lock file on that machine
composer install --no-dev
will only install the "normal" requirements, no dev-requirements like phpunit or other stuff you only need for developing or testing but not live
composer install --no-dev -o
will also optimize (-o) the auto loader, so it'll be a bit faster.
composer update
will update your packages, which might have funny side effects and break your site. So use it carefully and test afterwards.
composer update silverstripe/framework
will just update that package and finally
composer update silverstripe/*
will update all packages by the vendor silverstripe (e.g. framework and cms package)
See also:
gitignore documentation
composer documentation
I just started my laravel course with laracast. I dont quite understand yet all the enviornment-related things.
I know that Composer is a kind of a program that downloads pre-written scripts to use in your project. But where does it work? On my local machine or on my vagrant homestead box VM? On which of these is it supposed to be installed?
I installed myself vagrant homestead box already but does it contain composer? When I go ssh into my guest machine and go to vagrant#homestead:/vagrant$ path I can see composer.json and composer.lock files, but does it mean that I have composer installed?
Composer is a PHP package manager, like npm for javascript or pip for python. There are many examples of package managers. It's useful, because adding dependencies to your php projects can be a pain, but composer makes it really easy. You just add the dependency to composer.json and you can use it right off the bat.
Composer isn't laravel specific, you can use it in any php project, laravel uses it to manage it's dependencies, laravels dependencies use it to manage their dependencies and so forth.
If nothing else, the composer autoloader is great, so you can use it even if you don't plan on using external packages.
Homestead should come with composer installed. A composer.lock file is generated when you run a composer install or composer update. If you plan on creating or using other php projects on your machine, it's probably a good idea to have composer installed on your machine as well.
I'm trying to update the old server, which runs Symfony 2.0.X and vendors to the latest version 2.0.23 with Vendors.
Unfortunatelly I can't find anywhere I can find Symfony 2.0.23 with vendors. On official site:
http://symfony.com/download
And on GitHub:
https://github.com/symfony/symfony/releases/tag/v2.0.23
None of them have a version with Vendors. The download is only about 180 KiB. While version with Vendors is About 8 MiB.
Also, can I use Symfony 2.0.23 and vendors folder from Symfony 2.3.1 ? Is that compatible.
Also, maybe anyone heard about "Export" option for Git and Windows 8, or at least Ubuntu, so I could "Export" vendors from our "old Symfony version with Vendors"?
Thank you guys :)
What about downloading the corresponding deps and deps.lock files from the Symfony Standard Edition v2.0.23 and run bin/vendors locally?
Then export the project using git archive -o latest.zip HEAD (see this question). This will keep off all those .git directories. You may need to touch your .gitignore and/or .gitattributes file to be sure that the vendors aren't excluded on archiving.
Chances are very unlikely that you can run Symfony 2.0.23 with the vendor directory from 2.3.1
If you need to use Symfony 2.0.23 then its probably easiest to use composer.
Otherwise, I know they keep an archive of previous versions on the Symfony website but I'm pretty sure they do not include the vendor directory.