On Thu, 8 Sep 2016, at 11:35 AM, Lester Caine wrote: > I know this is a problem for PHP_CodeSniffer to rework it's > documentation, but it is a chicken and egg. PEAR provides a framework to > store things like PHP_CodeSniffer in the common area away from our web > folders. A similar set of guidelines to install via composer are needed > as an alternative and those are not currently in place? The point I > think here is that removing the built in installer for one off users is > what is being discussed and that should only happen if there is an > alternative. While composer can be used as an alternative, is it really > the best alternative for a simple built in loader?
Most people develop and host in different environments, when installing a package via composer for development purposes, you simply add it to the require-dev section of composer.json and run: "composer install", when it's time to deploy to the production environment, do "composer install --no-dev" and it will not install development dependencies, so PHP_CodeSniffer will not exist in any of your web folders. It wouldn't even matter for most if they didn't skip the development dependencies in production, since the vendor directory should live outside of the web root. Most packages that are actively maintained would have moved to Composer/Packagist by now, those that are still requiring installation via PEAR are probably not updated as frequently, and likely are still using styles and patterns from the PHP 4 era. -- Daniel Morris dan...@honestempire.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
