8

I'm having an issue with composer. I'm working with git in a local environment. I'm the only one developer.

When I need some more dependencies (or need to change some versions), I edit the composer.json and run composer install locally.

Everything's fine.

Then, when everything works locally, I commit my changes (including composer.json and composer.lock) and push to my production server.

A post-receive script updates the sources and runs a composer install on the remote server.

What is expected :

  • Composer should install the new dependencies according to the composer.lock file.
  • I should be happy.

What happens :

  • Composer is angry :

Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.

  • Composer removes all dependencies.
  • My production is broken.
  • I have a heart attack
  • I have to log in to my server via ssh and run a composer update to make things work fine, but I know that a composer update is not recommended on a production server.

Here's the output of the post-receive composer's section :

composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.
  - Removing guzzle/guzzle (v3.9.3)
  - Removing symfony/event-dispatcher (v2.7.1)
  - Removing geoip/geoip (v1.15)
  - Removing pimple/pimple (v3.0.0)
  - Removing cocur/slugify (1.1.x-dev)
  - Removing bentools/url (0.2)
  - Removing bentools/simplexmlextended (1.2.0)
Generating autoload files

What am I doing wrong ?

Thanks, Ben

Ben
  • 845
  • 1
  • 8
  • 18

2 Answers2

5

This warning

Warning: The lock file is not up to date with the latest changes in composer.json, you may be getting outdated dependencies, run update to update them.

occurs when the md5sum of your composer.json differs from the one stored in the composer.lock:

{
    "hash": "b15ed9405e8547867f74973ce8add172",
    "packages": [ ... ]
}

Make sure your composer.json and composer.lock are identically with your local ones (compare their md5sums). I suspect that something in your deploy chain is not updating them correctly.

Make sure you added your dependencies locally with the require command:

composer require new/package ~2.5

or if composer.json was edited manually at least run 

composer update new/package

after that for every additionally added package to ensure that it is added to your composer.lock properly.

Another approach:
run composer update --lock in production. This will update the hash in your lock file but won't upgrade your vendors.

Then run composer install to install the vendors from your comoser.lock.

Pᴇʜ
  • 56,719
  • 10
  • 49
  • 73
0

When I need some more dependencies (or need to change some versions), I edit the composer.json and run composer install locally.

That's wrong. You can edit composer.json and then must run composer update, or you let Composer do the internal editing of the json file and just run composer require new/package (optionally with a version).

Either way, you should end up with a changed composer.json and composer.lock file, commit BOTH into your repository, and the expected outcome is that the lock file will contain all packages in the correct versions, which should be installed in production with a regular composer install run.

Note that your workflow is still very dangerous. If you push, and Github is down - how would you get the ZIPs to install?

Sven
  • 69,403
  • 10
  • 107
  • 109
  • OK, I'll do it this way then. For the case github is down, what is your advice ? – Ben Jul 02 '15 at 12:31
  • Neither Git nor Composer are deployment tools. They get used as such a lot, but that doesn't mean it's the best solution. In general, you'd put together a ZIP or TGZ containing all code needed for the production update (including the code in Git as well as everything from Composer), move it to the production machine, unpack it, (test it in a hidden place - optional), and then switch to it instantly. There are tools for this - Capistrano is one of them. To avoid Github downtimes and faster access, use Satis to create a local copy of dependencies you use. Details would warrant a new question. – Sven Jul 02 '15 at 12:53