Re: [RFC] Deprecate PEAR/PECL & Replace withcomposer/pickle
| From: | Christoph M. Becker | Date: | Thu, 08 Sep 2016 11:33:37 +0000 |
| Subject: | Re: [RFC] Deprecate PEAR/PECL & Replace withcomposer/pickle | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95788@lists.php.net to get a copy of this message | ||
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