Composer Dependency Woes

I spent the better part of this afternoon trying to figure out why a Composer installation wasn’t working and finally figured out the problem…it wasn’t mine.

First, a little context – I’m currently working on a testing presentation for some folks at work and I wanted to show them how to work with the Behat testing tool to create some handy functional/integration tests for our framework-based apps. I threw together a little framework (yes yes, I know) and got the PHPUnit tests set up and running in no time. When it came to the Behat tests, though, no matter what I did, I was still having a problem:

[php]
PHP Fatal error: Class ‘GoutteClient’ not found in /www/htdocs/testing-examples/app/vendor/behat/mink/src/Behat/Mink/Driver/Goutte/Client.php on line 13
[/php]

No matter how I tried to configure the composer install, it always gave me this message. I tried everything I could think of and, finally, at the suggestion of Rafael Dohms, checked out the github repository for the Goutte client (a href=”http://github.com/fabpot/goutte”>here). As it turns out, in the past day or so, there’s been a large change where Fabien implemented composer support on the repo.

Apparently this was what broke things – thankfully not something obvious I was missing.

So, how did I solve it so I could see the lovely green of passing tests again? Well, if you’re familiar with composer, you know there’s a composer.lock file that’s created after you install. When you run the “composer install” and it fetches from “fabpot/goutte”:”*”, you get this latest version that has the issues. A quick modification of the composer.lock file takes care of that though:

[php]
{
"package": "fabpot/goutte",
"version": "master-dev",
"source-reference": "5ecceb7c28a428fb93f283982cc4f5edfd96630b"
},
[/php]

See that “source-reference” setting? Well, that can either point to the branch or version you want to pull from or it can point to a specific commit. In my case, I just pulled the hash for the commit before all of the changes and dropped it in there. Then it’s just a matter of running a “composer install” to get the code from this commit instead. Don’t run an update though – that will wipe out your manual changes to the lock file and you’ll be back to square one.

Hope this helps someone out there who might be dealing with a similar issue regarding brokenness on an external lib!

3 comments

  1. That’s a useful hint, however I’d say this is related to having chosen “master-dev” as the required version which pulls latest in goutte’s case.

    It’s just living on dev sources 😉 fresh and cool until you need something stable for a presentation 😉

    Like

    Reply

  2. I think you should change your composer.json to rely on this commit (keyword: reference). And then you can run composer.phar update and don’t break your lock (or app).

    Like

    Reply

  3. Composer actually supports referencing a particular commit in the composer.json for cases like this one, where you are using a development version but want to pin it for a demo for example.

    See the explanation in https://github.com/composer/composer/blob/master/doc/04-schema.md

    require and require-dev additionally support explicit references (i.e. commit) for dev versions to make sure they are blocked to a given state, even when you run update. These only work if you explicitly require a dev version and append the reference with #. Note that while this is convenient at times, it should not really be how you use packages in the long term. You should always try to switch to tagged releases as soon as you can, especially if the project you work on will not be touched for a while.

    Example:

    {
    “require”: {
    “monolog/monolog”: “dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7”
    “acme/foo”: “1.0.x-dev#abc123”
    }
    }

    Like

    Reply

Leave a comment