Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
Date: Mon, 5 Sep 2016 11:31:28 -0400
Message-ID: <CAEUnE0dzB0sB_kNFDRbbqOi3GzXLeONjA+NCd=HS2-aewdosMA@mail.gmail.com>
To: Davey Shafik <me@daveyshafik.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11425a32c4206f053bc45ff7
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
From: tendoaki@gmail.com (Michael Morris)

--001a11425a32c4206f053bc45ff7
Content-Type: text/plain; charset=UTF-8

Please be cautious - composer isn't a complete replacement for PEAR because
it doesn't behave the same way. For the most part this is a good thing, but
please consider the following.

On not one but two occasions I was tasked after being hired with upgrading
PHP versions from 4.x to 5.3.  In both cases the programmers on staff who
had inherited the balls of mud in question swore up and down it couldn't be
done - on both occasions it was because they weren't copying the PEAR
libraries over to the new PHP install.

PEAR is a global installer, and unfortunately I imagine there are a lot of
legacy sites that have been inherited by inexperienced coders who don''t
know what it is (cause it is used so rarely these days) that have pear libs
in use. If they need to build a new version of PHP they are at a complete
loss unless they know what they are doing because, more often than not, the
requirement of pear libraries in PHP apps that use them go undocumented.

Composer is superior for several reasons, but one of them is that it
doesn't share this flaw. The requirements of a composer project are listed
explicitly in the composer.json file - often down to the version # of the
code in question.

While abandoning PEAR seems sensible, abandoning its plugins, not so much.
To say nothing of PECL extensions which are, if I recall correctly, written
in C++ and extend the PHP runtime directly.

Also, as Tony Marston pointed out, there are CPanel systems that allow the
pear libraries to be managed from a web gui.  Given time I'm sure the folks
at cpanel will build new interfaces for new systems if it's possible.
Composer however doesn't really allow for this since the dependencies
belong to the PHP application, not the server. Does it make sense for any
new system to allow for server wide installing?  Composer does have global
requiring, but it's usually for support tools meant for use at the command
line like PHP Unit.

Despite the misgivings above, I do support the aims of this RFC and hope
they are considered going forward.

On Fri, Sep 2, 2016 at 3:32 PM, Davey Shafik <me@daveyshafik.com> wrote:

> Hi internals,
>
> 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
>
> I highly recommend reading the twitter poll and accompanying thread at
> https://twitter.com/dshafik/status/756337267547832320
>
> I believe that pickle solves the issues with regards to pecl, and have run
> the idea passed Jordi and Pierre. Both are fine with this RFC. :)
>
> I understand that adding in composer/pickle is just setting us up for
> having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
> I've proposed the voting reflect that some people will just want to
> deprecate/remove pear/pecl and not replace them at all.
>
> I'm also proposing voting choices around the optional/default introduction
> of composer/pickle.
>
> - Davey
>

--001a11425a32c4206f053bc45ff7--