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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
