Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95801
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ncsu.edu from 209.85.217.181 cause and error)
MIME-Version: 1.0
In-Reply-To: <bac1fc14-99bf-fc2e-39ce-a1662092785d@lsces.co.uk>
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>
Date: Thu, 8 Sep 2016 11:02:41 -0400
Message-ID: <CADMz3weWurQpusUSkCx=25c6fxuWArSzQaedr4HnGVrLc11PzQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace withcomposer/pickle
From: mdwheele@ncsu.edu (Dustin Wheeler)

Hi Lester,

>
> Currently having followed the installation guide I have things working
> on a home directory. This is probably what people expect today, but I
> still expect tools to be available which ever login I use ... testing
> different client profiles.
>

There are a few options, as I'm sure you're aware, haha. By default,
global requirements are going into the executor's home directory.
However, you can configure all of those paths at run time. My advice
(if you cannot (or simply prefer not to) install these types of tools
per-application) would be to configure those paths to point to some
global space in (what I presume is a) shared development space where
it makes sense to have these tools installed globally (phpcs, phpunit,
etc). Then you would have the task of making sure that global bin-path
is in each users environment when they log in.

However! (and I don't know if this is "best practice" or whatever) ...
you *could* decide to specify bin-dir to be some UNIX / Windows path
that is in environments by default. The risk here is that you collide
with pre-existing binaries / symlinks (which is a trade-off to global
installations in general). Let's see what we can do...

```bash
# For purposes of demonstration, I'm doing this as a user that can create
# directories in /opt and can create and execute files in /usr/local/sbin
# I wouldn't do this as root, I'm just lazy...
$ sudo su -
$ whoami
root

# Arbitrarily decide to install here globally
$ mkdir /opt/composer

# Tell composer where to install dependencies
$ composer global config vendor-dir /opt/composer/vendor

# Tell composer where to put "binaries" (symlinks)
$ composer global config bin-dir /usr/local/sbin

# Verify our settings "took"
$ composer global config --list
<snip>
[vendor-dir] /opt/composer/vendor
[bin-dir] /usr/local/sbin

# Note that there are other paths that should probably be specified
(where caches are stored, etc)
# In this example, Composer's global config is in-fact in root's home
directory. Caches are in root's
# home directory. This may or may not be acceptable, but is definitely
configurable to whatever you want

# Install PHPCS globally and cross fingers >_<
$ composer global require squizlabs/php_codesniffer

# Drop elevated permissions
$ exit
$ whoami
vagrant

# Try to use PHPCS out of my home directory with no special pathiness...
$ which phpcs
/usr/local/sbin/phpcs

$ phpcs --version
PHP_CodeSniffer version 2.7.0 (stable) by Squiz (http://www.squiz.net)
```

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.

I'll admit that most folks (it seems, anecdotally) have gone the way
of installing these development tools per-application using
`require-dev` but I completely understand where you're coming from. I
just wanted to show you what's possible.

I hope this helps, Lester.

-Dustin

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwheele@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."