Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95806
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error)
To: internals@lists.php.net
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
 <04998da0-6344-0b8b-c69a-411400e340ba@lsces.co.uk>
 <1473323097.1378681.719308017.2139F909@webmail.messagingengine.com>
 <8493a9dd-1f0e-f15f-3651-0278cf25234b@lsces.co.uk>
 <ec690b39-00d3-b2f7-60e7-5dd5b30cd7b3@gmx.de>
 <e8584697-8efe-e933-ca74-a404c92c30ec@lsces.co.uk>
 <CANUQDCgfcFtTOmKYj0osvsOwVOi2Y3SkAXGFyVdsFh0-UR04aA@mail.gmail.com>
 <bac1fc14-99bf-fc2e-39ce-a1662092785d@lsces.co.uk>
 <CADMz3weWurQpusUSkCx=25c6fxuWArSzQaedr4HnGVrLc11PzQ@mail.gmail.com>
 <3ec68c67-a4de-1727-c3c8-e8fcacd95f0c@lsces.co.uk>
Message-ID: <b9ea0155-2f4b-bbfe-2ecd-6e7700147ad4@garfieldtech.com>
Date: Thu, 8 Sep 2016 12:40:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <3ec68c67-a4de-1727-c3c8-e8fcacd95f0c@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 withcomposer/pickle
From: larry@garfieldtech.com (Larry Garfield)

On 09/08/2016 11:21 AM, Lester Caine wrote:
> On 08/09/16 16:02, Dustin Wheeler wrote:
>> In this way, you *can* install composer "binaries" to a global
>> location that is accessible by default by normal users on your system.
>> This was done on a CentOS 7 machine, but I am positive this can be
>> equivalently applied to Windows or any environment, really.
> Another couple of hours wasted, but I understand where things are now,
> and basically the simple fact is that composer global mode is nothing of
> the sort. The PHP_CodeSniffer composer install does not work and I
> understand NOW why the Smarty one also failed. I was expecting the files
> to be available to the nginx server but they were hidden away in my home
> directory. I still have to work out just how to reset things to move the
> code to /usr/shared/phpx/composer to parallel the PEAR version.
>
> The main feedback here has been that nothing should be removed until
> there is a working alternative, and I think there DOES need to be a
> discussion on making a default installation of composer that provides a
> global installation for tools like PHP_CodeSniffer and other global
> tools before the current option is slated for deprecated.
>
> My target client machines are windows rather than linux and each IT
> technician has their own login and these change year on year, so the
> tool chains all need to be globally installed, something PEAR is
> designed to provide? An installation of composer needs to emulate that
> model at the 'PHP' level otherwise we are looking at a major BC break?

In any practical sense, the PHP community at large has abandoned 
system-level installation of tools over the course of the past decade.  
That was one of the downfalls of PEAR: System-level installation of a 
package whose stability wasn't measured in RHEL LTS releases are 
basically a non-starter.

Just about every PHP tool I can think of these days, save PEAR/PECL, is 
designed to be installed per-user ("global") or per-project (most 
composer).  That's how they *want* to be used.  Trying to fight that 
trend is setting yourself and your users up for a world of pain.

Note: Whether that is a good trend or bad trend I will not claim, and 
that is largely irrelevant.  But that is where the river is running, and 
trying to swim upstream against it is not going to be very effective.

(The Python community has also made steps in that direction with 
virtualenv, which lets you avoid system-global code, too.  Time will 
tell how far that process goes there.)

--Larry Garfield