Task #59515
closed
Ship composer.lock file as well
Added by Fabien Udriot over 10 years ago. Updated about 7 years ago.
100%
Description
composer.lock file has the effect to lock the version
of the Composer packages we require for TYPO3 CMS
when running `composer install` and should be part
of the distribution in this regard.
More info here: http://stackoverflow.com/questions/12896780/composer-lock-part-of-the-repository
Updated by Gerrit Code Review over 10 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/30684
Updated by Benni Mack almost 10 years ago
- Status changed from Under Review to Rejected
Should be included in the distribution, not in the core itself.
Updated by Gerrit Code Review over 9 years ago
- Status changed from Rejected to Under Review
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971
Updated by Markus Klein over 9 years ago
- Status changed from Under Review to New
- Priority changed from Should have to Must have
- Target version changed from next-patchlevel to 7.3 (Packages)
Some detailed information on the .lock and .json topic.
The .lock file holds the exact commit/version of every dependency (recursively) of the source (in our case CMS Core).
The .json file defines a range (can of course be narrowed down to a single version) of versions allowed for the dependencies.
Composer itself treats the .lock file of a project in a special way. The .lock file is only considered on the top-most level. Lock-files of dependencies are ignored. [1]
The CMS Core might be used in two ways:Commit your application's composer.lock (along with composer.json) into version control. [2]
- As standalone source
- As a "library" for another composer-based project
Standalone source
The basic process is:- Checkout tag of version
- Run `composer install`
In this case we should provide the .lock file (as this is the top-most project) to ensure that all versions of all dependencies are really fixed.
This is also important for CI. [3]
If we do not provide a .lock file this issue will occur:
- The user installs the first time using the procedure above.
- After a new release the user repeats that process (which is correct!)
- The `composer install` now fails to update the dependencies, since the existing .lock file (based on the first install) is not updated.
(The user would need to run `composer update`, which would be wrong, since this command is intended for developer usage to get the newest updates for the dependencies.)
Composer-based project
The Core is referenced as requirement in the project's composer.json and is loaded when `composer install` is run for the project.
The .lock file of the CMS Core will be ignored.
In order to ensure a stable Core, we need to ensure our .json requires only safe ranges of versions of dependencies. (we already do that)
In order to properly support both ways of using the Core and to further strengthen the CI environment, we should include the .lock file into the GIT repository.
(This patch should also go into 6.2 IMHO.)
[1] https://getcomposer.org/doc/02-libraries.md#lock-file
[2] https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file
[3] https://blog.engineyard.com/2015/composer-continuous-integration
Updated by Helmut Hummel over 9 years ago
Markus Klein wrote:
The CMS Core might be used in two ways:
- As standalone source
This is only recommended for developers.
Users should download the packaged version
- As a "library" for another composer-based project
In that case the lock file is obsolete.
The .lock file is of utmost importance, if we change dependencies in a release.
If we do not provide a .lock file this issue will occur:
- The user installs the first time using the procedure above.
- After a new release the user repeats that process (which is correct!)
- The `composer install` now fails to update the dependencies, since the existing .lock file (based on the first install) is not updated.
(The user would need to run `composer update`, which would be wrong, since this command is intended for developer usage to get the newest updates for the dependencies.)
Imho no user would do a composer install. Besides that, we will never change composer dependencies for a released tag (obviously).
Updating TYPO3 to a version with changed dependencies means update or upgrade of TYPO3 and I think composer update (is logical there as well).
It is just a matter of documenting that.
Composer-based project
The Core is referenced as requirement in the project's composer.json and is loaded when `composer install` is run for the project.
The .lock file of the CMS Core will be ignored.
In order to ensure a stable Core, we need to ensure our .json requires only safe ranges of versions of dependencies. (we already do that)
Exactly.
In order to properly support both ways of using the Core and to further strengthen the CI environment, we should include the .lock file into the GIT repository.
In CI environments, you always checkout a clean state and do a composer install on that. This will result in the exact same state if our dependencies are pinned to a version. There is no benefit here.
(This patch should also go into 6.2 IMHO.)
I disagree. In 6.2 the recommended way to use a core checkout is to just use it. No composer install is required there at all
To sum up my view:
Pro to commit composer.lock
- A composer install is always enough to get the correct dependencies, even after a repo update
- Dev dependencies (basically phpunit) are locked to a certain version
Cons to commit composer.lock
- We need to commit an additional file into our repo, which only changes if we change the dependencies
- If we change dependencies, we need to take care to update the lock file and commit it.
- Dev dependencies (basically phpunit) are locked to a certain version - which means more work when we want regular updates
I really do not see any benefits, just (a tiny bit) more work when commiting the composer.lock file
Updated by Gerrit Code Review over 9 years ago
- Status changed from New to Under Review
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971
Updated by Benni Mack over 9 years ago
- Target version changed from 7.3 (Packages) to 7.4 (Backend)
Updated by Gerrit Code Review over 9 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971
Updated by Gerrit Code Review over 9 years ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971
Updated by Gerrit Code Review over 9 years ago
Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971
Updated by Gerrit Code Review over 9 years ago
Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971
Updated by Markus Klein over 9 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset b35fe07082fc32e2e1d5f6469158f730c52f8afe.
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Resolved to Closed