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: mdwhe...@ncsu.edu | w: 5-9786 "If you don't know where you're going, it's easy to iteratively not get there." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
