Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95729
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
To: internals@lists.php.net
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
 <b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com>
 <A8.67.32927.27DDBC75@pb1.pair.com>
 <CANUQDCjeH45_2aEq74CCEOY4xc3xJ0o_+yRQ2NVy0K2VdOXFBQ@mail.gmail.com>
 <C9.2F.45301.38D6EC75@pb1.pair.com>
 <CAH-PCH5qHdYen33Q_s7kTKM_8qK71v8Ky6kT4fzuRfAwfX06BQ@mail.gmail.com>
 <A7.D5.18051.896CFC75@pb1.pair.com>
 <CAH-PCH568TPsztkWT553QVQy7jsp1tcqT5w+OT1PoCDt-PbUOg@mail.gmail.com>
 <780c8f3d-bc26-37ff-893d-54be8d438c73@lsces.co.uk>
Message-ID: <7ecffe19-f7be-7b51-f952-013812851c2c@gmail.com>
Date: Wed, 7 Sep 2016 10:58:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <780c8f3d-bc26-37ff-893d-54be8d438c73@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
 composer/pickle
From: rowan.collins@gmail.com (Rowan Collins)

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]