Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95788
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.19 as permitted sender)
To: Lester Caine <lester@lsces.co.uk>, internals@lists.php.net
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>
Message-ID: <ec690b39-00d3-b2f7-60e7-5dd5b30cd7b3@gmx.de>
Date: Thu, 8 Sep 2016 13:33:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <8493a9dd-1f0e-f15f-3651-0278cf25234b@lsces.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace withcomposer/pickle
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 08.09.2016 at 12:35, Lester Caine wrote:

> On 08/09/16 09:24, Daniel Morris wrote:
>> On Thu, 8 Sep 2016, at 09:07 AM, Lester Caine wrote:
>>> I've just been through an exercise to give PHP_CodeSniffer a go on my
>>> code base. I've not worried too much about that in the past since
>>> Eclipse in general flags style problems as well as simple errors. This
>>> is a package that SUSE does not support, so the current install path is
>>> just PEAR. I don't see packages like this as a library that my sites
>>> use. It is a stand alone tool ( and a command line one at that :) ) so
>>> how would loading that be managed if PEAR is not available?
>>
>> PHP_CodeSniffer is already compatible with Composer, and Composer has
>> the ability to specify dependencies, and dependencies intended for
>> development. After running composer install you can execute
>> `vendor/bin/phpcs`, and if you were working collaboratively,
>> collaborators would all have the same toolset that you have.
> 
> I know this is a problem for PHP_CodeSniffer to rework it's
> documentation, 

The docs seem to be fine:
<https://github.com/squizlabs/PHP_CodeSniffer#installation>.

> 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 `global` command appears to solve that:
<https://getcomposer.org/doc/03-cli.md#global>.

-- 
Christoph M. Becker