composer.lock not respected #890

dbu opened this Issue Jul 9, 2012 · 20 comments


None yet

7 participants

dbu commented Jul 9, 2012

since recently, i see that composer reports conflicts even when there is a composer.lock. in my understanding, it should trust the information of composer.lock. additionally i get conflicts on dependencies that should not be needed at all.

how to reproduce

git clone
cd cmf-sandbox
composer.phar install

the report is

Problem 1
- midgard/phpcr dev-master requires ext-midgard2 >=10.05.5 -> no matching package found.
- jackalope/jackalope-jackrabbit dev-getNodesByIdentifier requires jackalope/jackalope dev-master -> satisfiable by jackalope/jackalope dev-master.
- jackalope/jackalope dev-getNodesByIdentifier requires jackalope/jackalope-transport dev-master -> satisfiable by jackalope/jackalope-jackrabbit dev-getNodesByIdentifier.
- Can only install one of: jackalope/jackalope dev-master, jackalope/jackalope dev-getNodesByIdentifier.
- doctrine/phpcr-odm 1.0.x-dev requires phpcr/phpcr-implementation 2.1.0-beta3 -> satisfiable by midgard/phpcr dev-master, jackalope/jackalope dev-getNodesByIdentifier.
- symfony-cmf/symfony-cmf 1.0.x-dev requires doctrine/phpcr-odm 1.0.* -> satisfiable by doctrine/phpcr-odm 1.0.x-dev.
- Installation request for symfony-cmf/symfony-cmf 1.0.* -> satisfiable by symfony-cmf/symfony-cmf 1.0.x-dev.

it was correct at that point that phpcr-odm had a dependency on phpcr/phpcr that prevented the most recent jackalope from being installed. but the lock file was specifying the exact versions that would have been installable. imho composer should just follow composer.lock when running composer install and not try to resolve dependencies with information from packagist that might has changed since composer.lock was created.

stof commented Jul 9, 2012


stof commented Jul 17, 2012

We talked a bit about it on IRC. Trusting blindly the lock file would be the only way to really lock the dependencies. But it would also require changing the lock file to store the complete package definitions in it. The current format requires getting the package metadata from the repository, where they could have changed since the locked version. The example above is a good example.

dbu commented Jul 17, 2012

not sure how tightly related this is, but i noticed that having an existing checkout, updating the project and then composer install sometimes does not the same as the exact same command but with the vendor directory deleted. and i we did not manually play with the git remote settings or anything.

if there are valid use cases for both behaviour, we might need options to tell composer what we want. but i think one valid usecase is that i can just be dead sure to reproduce the same state of my project, whether updating or with a fresh checkout.

Seldaek commented Jul 18, 2012

Agreed, I guess we need to change the lock format to be a complete copy of the installed stuff and just install from that. @naderman any additional thoughts?

markri commented Jul 20, 2012

As far as my understanding goes for composer, I also face this problem. I guess it always fetches the latest composer.json from the repository instead of the composer.json from the revision locked in composer.lock.
Shouldnt this be the other way around? So first cloning every dependency it needs, then set it to the right revision, and then checking the versions? Or maybe there is even a better way to get the right composer.json from the repository?

An extra command line argument to ignore version checking might be a good option for now? Sure its probably not the best fix, but will set this issue from blocking to an improvement.

dbu commented Jul 20, 2012

if what @mdekrijger writes is correct (composer downloading the .json for dependencies on install), then i am really confused. imho on install from .lock composer does not need to re-validate the installation at all. the validation happened when the .lock file was written and if we can checkout all repositories at the commit ids saved in the lock, there is no need to revalidate - on the contrary.

additionally, this could be the better hack entry point then disable validation, as i could manually edit the .lock to construct a checkout that would not be fully valid, if i know exactly what i do.

Seldaek commented Jul 20, 2012

Composer never reads the composer.json of dependencies, it needs to know
the dependencies of each package in advance to be able to solve them, so
we can not do this "checkout then check composer.json then checkout
again". As I said, reading the lock file and applying it as-is probably
makes sense.

ricbra commented Jul 30, 2012

Is there any news on this issue? It would be cool if composer would just install when there's a lock file and not complaining about dependency problems. These are quite difficult to solve: first you need to find the vendor which changed its dependencies and then fork the vendor and change the composer.json in your fork.

stof commented Jul 30, 2012

@ricbra this is not fixed yet. It is not easy to fix. The content available in the lock file currently simply does not allow installing without reading external metadata. It requires changing totally the content of the lock file.
and @Seldaek is in vacation right now so such big change probably needs to wait until he comes back.

rdohms commented Jul 31, 2012

I think only one think should be noted. Composer should trust the lock file blindly but i think it should first compare the require of the json file and the lock file, so that if there is an extra or missing package in any of them it should still alert us that there is a difference and upgrade should be executed. Because in this case you are changing the actual dependencies and you don't want people to forget the update in this case.

stof commented Jul 31, 2012

@rdohms it already checks if the lock file is outdated. The issue is that it cannot trust it blindly currently as the lock file does not contain all metadata. It has to read them from packagist, and they can have changed for dev versions.

rdohms commented Jul 31, 2012

@stof yeah just thought to comment so that this is not bypassed in the rewrite

Gladhon commented Aug 2, 2012

@stof isn't possible to get old metadata by looking for composer.json in the old commit found in lock file ?

stof commented Aug 2, 2012

@Gladhon metadata are not in the composer.json. They are on packagist. What you would need would be to be able to access the packagist metadata from the past (or the git branches from the past when using a VCS repo), which obviously does not work.

Gladhon commented Aug 2, 2012

Okay, for now, i just done a ugly workaround by setting needed information in "repositories" in composer.json. Perhaps something like repositories.lock could help.

stof commented Aug 2, 2012

@Gladhon what would you put it repositories.lock ? The whole content of packagist at this time ?

Gladhon commented Aug 2, 2012

Not the "whole" but the whole of the package-version is definied by composer.
For now i've setting old informations my self, for example for sonata-admin, and the install works like expected (with old dependecies. Perhaps it's possible to generate a repositories.lock and load it on install process.

   "repositories": [ 
            "type": "package", 

            "package": {

                            "name": "sonata-project/admin-bundle",
                            "type": "symfony-bundle",
                            "description": "Symfony SonataAdminBundle",
                            "keywords": ["Admin Generator", "admin", "sonata", "bootstrap"],
                            "homepage": "",
                            "license": "MIT",
                            "authors": [
                                    "name": "Thomas Rabaix",
                                    "email": "",
                                    "homepage": ""
                                    "name": "Sonata Community",
                                    "homepage": ""
                            "require": {
                                "php": ">=5.3.2",
                                "symfony/symfony": "2.1.*",
                                "symfony/framework-bundle": "2.1.*",
                                "symfony/security-bundle": "2.1.*",
                                "knplabs/knp-menu-bundle": "dev-master",
                                "sonata-project/jquery-bundle": "dev-master",
                                "sonata-project/exporter": "dev-master",
                                "sonata-project/block-bundle": "dev-master"
                            "require-dev": {
                                "jms/translation-bundle": "*"
                            "suggest": {
                                "sonata-project/doctrine-orm-admin-bundle": "dev-master",
                                "sonata-project/intl-bundle": "dev-master"
                            "autoload": {
                                "psr-0": { "Sonata\\AdminBundle": "" }
                            "target-dir": "Sonata/AdminBundle",            
                            "version": "dev-master",
                            "source": {
                                "url": "git://",
                                "type": "git",
                                "reference": "47fdb8677041d896b3443705e5906af3850430e2"

stof commented Aug 2, 2012

if you read what has been suggested above, we wanted to store the whole metadata of the installed package in the composer.lock file. I don't see why another lock file would be needed.

Gladhon commented Aug 2, 2012


@Seldaek Seldaek closed this in 83239aa Sep 14, 2012
Seldaek commented Sep 14, 2012

Alright, fix pushed, quite hard to test but it should help, let us know if the install is still unreliable.

@digitalkaoz digitalkaoz pushed a commit to digitalkaoz/composer that referenced this issue Nov 22, 2013
@Seldaek Seldaek Update lock file to contain the complete package info, fixes #890 788e754
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment