Re: [RFC] Deprecate PEAR/PECL & Replace withcomposer/pickle

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