Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95728
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rochette.cc designates 62.210.206.189 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: <aafe67b0-2038-3fb0-0e01-640084f27e93@rochette.cc>
Date: Wed, 7 Sep 2016 11:57:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101
 Thunderbird/50.0a2
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
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
 composer/pickle
From: mathieu@rochette.cc (Mathieu Rochette)



On 07/09/2016 11:33, Lester Caine wrote:
> On 07/09/16 09:10, Ferenc Kovacs wrote:
>>> I can only report what I have read in various newsgroups and forums, and
>>>> they have said that composer has screwed up their installations. If it is
>>>> capable of doing that then it is a serious issue that needs addressing.
>> you can, but you shouldn't spread FUD but do your own research.
>> composer will only do something when you execute it, without providing any
>> actual problem, there is no way those could be refuted (FUD), and brings
>> nothing to the discussion.
>> what you have probably seen is people not using the tool properly
>> from my experience people usually screw 2 things up:
>>
>>     1. executing "composer update" without any arguments which will update
>>     every package listed in your composer.json file to the latest version
>>     allowed by the version constraints
>>     2. not putting the composer.lock under version control and then being
>>     surprised that the other developer who makes a "composer install" from
>>     composer.json can have different(eg. more recent) versions installed
> 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.
composer.lock is supposed to be version controlled, so figuring out 
which package have been updated should not be a problem. besides, if you 
don't run "composer install" the package aren't going to be updated. but 
when you do, you will see which packages are update.
even if you run "composer update" without an argument, it should only 
update packages to "semver compatible" version of those package unless 
the version constraints have been manually entered to allow major 
version upgrade. obviously some package releases don't respect semver 
(either by ignorance/choice or because there is an unknown bug)

if you deploy an updated composer.lock in production and that it 
upgrades your dependencies. that means that it passes code review, CI 
and staging or that you don't do any of those. I don't think composer 
should be blamed for that

>
> I can see that composer has a place in a development environment and
> developers will be more than happy playing with that, running the right
> command line steps and keeping their set of composer controlled
> libraries up to date. The problem comes when 'publishing' a version of a
> project and ensuring that the production hosting has the right setup.
> The web based tools built into a distribution process will need to be
> able to educate users who have been happy with PEAR into the new style
> of working and it's that layer that needs to be at least prototyped
> before current functional systems are switched off.
"current functional systems are switched off." => this is not what is 
being proposed by the rfc!
the first potential vote is "Deprecate pear/pecl & unbundle in 8.0" if 
it passes, it means it won't be bundle with PHP and it will probably 
stopped being referenced in the documentation. but it will keep working, 
that's very different from "switched off"
>
> But I know the answer already ... not our problem :(
>