Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95671
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.177 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAEUnE0dzB0sB_kNFDRbbqOi3GzXLeONjA+NCd=HS2-aewdosMA@mail.gmail.com>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
 <CAEUnE0dzB0sB_kNFDRbbqOi3GzXLeONjA+NCd=HS2-aewdosMA@mail.gmail.com>
Date: Mon, 5 Sep 2016 11:57:59 -0700
Message-ID: <CANaX5ncua2WMfnBT7-sNWVAMACC5BQeWGPaNPGX9-Y7A1mYTXg@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114e6328555971053bc74285
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
From: me@daveyshafik.com (Davey Shafik)

--001a114e6328555971053bc74285
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 5, 2016 at 8:31 AM, Michael Morris <tendoaki@gmail.com> wrote:

> 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.
>

Even ten years ago, best practices was not to install PEAR packages
globally due to different projects on shared hosts needing different
versions. Instead we installed them locally, committed them to RCS, and
used the include_path to control include locations.


> 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.
>

Nobody is suggesting this. Though it might be good to push them off from
under php.net, that doesn't stop them existing, and that's not part of this
RFC.


> To say nothing of PECL extensions which are, if I recall correctly,
> written in C++ and extend the PHP runtime directly.
>

Written in C, and yes, that's the difference between PEAR and PECL, the
former are userland, the latter are written in C. This is where pickle
comes in.


> 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.
>

Actually, I think Tony is pointing to pear-web, a PEAR provided web
interface for PEAR itself (which can be used instead of the CLI tool).
Which isn't going away, it will just be unbundled. In 8.0.

Nothing we're doing changes anything for CPanel and the like except they
may now need to replicate the install part of PEAR themselves from the PHP
compilation.  It's very simple.


> Despite the misgivings above, I do support the aims of this RFC and hope
> they are considered going forward.
>

Thank you.

- Davey

--001a114e6328555971053bc74285--