Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95695
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <C9.2F.45301.38D6EC75@pb1.pair.com>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
 <b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com> <A8.67.32927.27DDBC75@pb1.pair.com>
 <CANUQDCjeH45_2aEq74CCEOY4xc3xJ0o_+yRQ2NVy0K2VdOXFBQ@mail.gmail.com> <C9.2F.45301.38D6EC75@pb1.pair.com>
Date: Tue, 6 Sep 2016 18:25:28 +0700
Message-ID: <CAEZPtU6aHYb9HsNXbXWp9q9PMoLYiJp=N1rjmspoFmHBEbDHxg@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
From: pierre.php@gmail.com (Pierre Joye)

Hi Tony,

On Tue, Sep 6, 2016 at 2:17 PM, Tony Marston <TonyMarston@hotmail.com> wrote:
> "Niklas Keller"  wrote in message
> news:CANUQDCjeH45_2aEq74CCEOY4xc3xJ0o_+yRQ2NVy0K2VdOXFBQ@mail.gmail.com...
>
>>
>> Tony Marston <TonyMarston@hotmail.com> schrieb am So., 4. Sep. 2016,
>> 10:38:
>>
>>> "Rowan Collins"  wrote in message
>>> news:b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com...
>>> >
>>> >On 02/09/2016 20:32, Davey Shafik wrote:
>>> >> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and
>>> >> remove
>>> >> in 8.0), as well as add composer/pickle (optional in 7.2, default in
>>> >> 7.3+)
>>> >> in their place.
>>> >>
>>> >> https://wiki.php.net/rfc/deprecate-pear-include-composer
>>> >
>>> >Hi Davey,
>>> >
>>> >I think this is a sensible idea. It basically accepts the reality that
>>> PEAR
>>> >is no longer the main place new users of PHP should look for 3rd-party
>>> >code.
>>> >
>>> >Thinking about the responses so far, I thought it would be useful to
>>> >enumerate just what PEAR is, and what is being proposed for removal. It
>>> >might even be worth adding a version of this to the RFC, in case it
>>> reaches
>>> >a wider audience who won't see this discussion.
>>> >
>>> >As I understand it, PEAR is:
>>> >
>>> >A1) A command-line package management tool for installing and updating
>>> >packages of PHP code over the Internet.
>>>
>>> Incorrect. There is a web interface which I use EXCLUSIVELY to maintain
>>> the
>>> contents of my PEAR library.
>>
>>
>>
>> You only work in a web interface instead of an editor and version control
>> system?
>
>
> PEAR does not have a version control system. My software has an SVN
> repository, but that is totally unconnected with PEAR. My choice of editor
> has no bearing on the issue.

It has, whether you need it or not is not really relevant to this discussion.

> I use the web interface to maintain PEAR on my local machine, and my hosting
> companies provide a web interface in their control panels.


Happy to see there are still users for this tool, Christian and I had
good fun writing it. Also you should know that this package is dead,
it has no acttve maintainer (I was the last one) and has some
limitations from to begin with, also was very handy at time especially
for shared hosting without shell access.

>> Packagist has a web interface to add new packages. New versions
>> (maintenance) are published automatically once you push a new version tag.
>>
>> Any proposed replacement which does not have a
>>>
>>> web interface I'm afraid is totally unacceptable. Command line interfaces
>>> went out of fashion when the Windows OS was first released, and anyone
>>> who
>>> still insists on using one has not joined the rest of the world in the
>>> 21st
>>> century.
>>>
>>
>> The Windows OS doesn't even have a built-in SSH client to maintain remote
>> systems.
>
>
> Then use 3rd party software. There are several available.

Your argument about GUI vs shell is totally irrelevant to this discussion.

>> Using a command line interface is much better for mintaining a server. No
>> web interface I'm aware of can compose different tasks as good as bash
>> with
>> using pipes to filter, sort, reformat, ...
>
>
> That may be your personal opinion, but it is not shared by others.

Again irrelevant and a wrong one. 95% of the web is run with systems
with shell only access, if at all. And yes, even recent windows
servers do that as well. However, whether you (I think it is fair to
say you can speak for yourself) like it or not (or anyone else) is not
relevant to this discussion.

>> Global libraries work for Linux distributions as there's a team behind
>> carefully watching that things are compatible. But PHP applications are
>> from different vendors. There's nothing that prevents conflicts.
>>
>> I do NOT want the replacement PEAR library to update itself in the
>>>
>>> background.
>>
>>
>> Composer doesn't do that.
>
>
> Then how come I've seen several complaints in various forums about composer
> updating libraries in the background and screwing things up.

Composer does not update libraries in the background, your project
dependencies being updated and you running composer update will update
them.

>> It has to be under MY control or I simply won't install it.
>>>
>>>
>>
>> You're in full control. There's even a lock file so everyone installing an
>> app can install the same version of every depenendy. That way it's way
>> easier to reproduce bugs locally.
>>
>> It has to be 100% stable, and I'm not sure that composer/pickle fit the
>>>
>>> bill.
>>>
>>
>> I can't talk for pickle as I haven't used it as I usually do not use any
>> additional extensions or compile them in directly.
>>
>> But I have never had any issues with the stability of Composer.
>>
>> There may be a small number
>>
>>
>> I don't think it's a small number. Almost all projects I know use
>> Composer.
>
>
> Exactly. Only the projects that YOU know use composer, but what percentage
> of all the PHP projects in the world does that cover?

Saying that even Wordpress is starting to implement composer support
says all I have to say about "usage".


>> The only one I know of that uses Pear is bugs.php.net.
>
> That proves nothing except that your knowledge is very limited.

I admire your enthusiasms but I strongly recommend to soften your tone.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org