On 07/09/2016 10:33, Lester Caine wrote:
This does highlight the different approach to handling things in a production environment over a development one. The problems I have seen IS when composer.lock gets replaced by mistake, or when an update picks up a change to a package that was not actually the one expected. Running around then like headless chicks trying to work out what is wrong is much like the problems when a hosting site simply switches from PHP5.3 to 5.4 without warning.
How is this any different from PEAR, or any other package or dependency management system? Managing the versions of shared libraries is a notoriously difficult problem - ever hear of "DLL hell"?
If anything, the Composer approach is simpler to deploy, because you can create a tar ball of the whole project with a populated vendor directory, and copy it straight to production. (I believe that's possible with PEAR, too, but not when using the standard shared-library configuration.) Or you can copy the composer.lock file (probably by committing to version control) and run "composer install" and get the same versions you had before without needing to manually go through a deployment checklist.
I think the bigger difference is in the style - and number - of dependencies people are pulling in. PEAR packages, in my experience, have a very strict compatibility policy, and most are at this point very stable simply because they're not at the cutting edge of development. So setting up a production server with a slightly different version of Cache_Lite is unlikely to cause that many problems.
The problems come when you're composing your application out of many dozens of small libraries, all actively developed, and some not being as careful as they should with stability. That's not Composer's fault, and if running your own PEAR channel was still common, you'd get the same thing.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
