Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95789
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain honestempire.com designates 66.111.4.28 as permitted sender)
Message-ID: <1473335050.1418268.719460889.354DDF33@webmail.messagingengine.com>
To: internals@lists.php.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
Date: Thu, 08 Sep 2016 12:44:10 +0100
In-Reply-To: <8493a9dd-1f0e-f15f-3651-0278cf25234b@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>
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
From: daniel@honestempire.com (Daniel Morris)

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
daniel@honestempire.com