Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

composer.lock not respected #890

Closed
dbu opened this Issue · 20 comments

7 participants

@dbu
dbu commented

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 git@github.com:symfony-cmf/cmf-sandbox.git
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

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

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
Owner

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

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

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
Owner
@ricbra

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

@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

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

@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

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

@Gladhon

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

@stof

@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

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

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

@Gladhon

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": "http://sonata-project.org/bundles/admin",
                            "license": "MIT",
                            "authors": [
                                {
                                    "name": "Thomas Rabaix",
                                    "email": "thomas.rabaix@sonata-project.org",
                                    "homepage": "http://sonata-project.org"
                                },
                                {
                                    "name": "Sonata Community",
                                    "homepage": "https://github.com/sonata-project/SonataAdminBundle/contributors"
                                }
                            ],
                            "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://github.com/sonata-project/SonataAdminBundle.git",
                                "type": "git",
                                "reference": "47fdb8677041d896b3443705e5906af3850430e2"
                            }                   

            }
        }
}   
@stof

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

agreed

@Seldaek Seldaek closed this in 83239aa
@Seldaek
Owner

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

@felixalias felixalias referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@felixalias felixalias referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.