On Thu, 8 Sep 2016, Davey Shafik wrote:
> Anyway, this is far off topic IMO. This RFC isn't going to kill PEAR
> (any deader than it already is :P) it will simply unbundle it from
> core. If you want to continue using it, then by all means do so. And
> ignore the potential fact that composer/pi
On Thu, Sep 8, 2016 at 3:18 PM, Lester Caine wrote:
> On 08/09/16 18:40, Larry Garfield wrote:
> > Note: Whether that is a good trend or bad trend I will not claim, and
> > that is largely irrelevant. But that is where the river is running, and
> > trying to swim upstream against it is not going
On 08/09/16 18:40, Larry Garfield wrote:
> Note: Whether that is a good trend or bad trend I will not claim, and
> that is largely irrelevant. But that is where the river is running, and
> trying to swim upstream against it is not going to be very effective.
Trying to swim against the tide of M$
On Thu, 8 Sep 2016, at 05:21 PM, Lester Caine wrote:
> Another couple of hours wasted, but I understand where things are now,
> and basically the simple fact is that composer global mode is nothing of
> the sort. The PHP_CodeSniffer composer install does not work and I
> understand NOW why the Smar
On 09/08/2016 11:21 AM, Lester Caine wrote:
On 08/09/16 16:02, Dustin Wheeler wrote:
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
equivalent
On 08/09/16 16:02, Dustin Wheeler wrote:
> 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 environmen
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
On Thu, 8 Sep 2016, at 01:13 PM, Lester Caine wrote:
> That is the chicken ... if you ARE already composer user then it will
> make some sense, but pear gives a phpcs -h which works out of the box.
> ./vendor/bin/phpcs -h does not sound right as an alternative? And I
> would expect different instal
On 08/09/2016 15:13, Lester Caine wrote:
bash: ./vendor/bin/phpcs: No such file or directory
Which I presume means I do need to set up some path, but currently I no
idea where 'composer global require "squizlabs/php_codesniffer=*"' has
put it?
That's the directory where it goes if you *don't* u
On 08/09/16 13:26, Niklas Keller wrote:
> That is the chicken ... if you ARE already composer user then it will
> make some sense, but pear gives a phpcs -h which works out of the box.
> ./vendor/bin/phpcs -h does not sound right as an alternative?
>
> Why does it seem not right? It's
2016-09-08 14:13 GMT+02:00 Lester Caine :
> On 08/09/16 12:33, Christoph M. Becker wrote:
> > 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 PH
On 08/09/16 12:33, Christoph M. Becker wrote:
> 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 worr
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
13 matches
Mail list logo
