Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95651
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
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 17:43:26 +0200
Message-ID: <CAH-PCH4KKaS3ofouFYPUaY1u-9f1_95U9KDDKAgX3Pcn57m70w@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: PHP Internals <internals@lists.php.net>, Davey Shafik <me@daveyshafik.com>
Content-Type: multipart/alternative; boundary=001a114428b89713de053bc48a5b
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a114428b89713de053bc48a5b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016. szept. 5. 17:32 ezt =C3=ADrta ("Michael Morris" <tendoaki@gmail.com>)=
:
>
> 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 upgradin=
g
> 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 o=
f
> 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 liste=
d
> 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 th=
e
> 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 globa=
l
> requiring, but it's usually for support tools meant for use at the comman=
d
> 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
> >

For the record pear support local install and composer also provides global
installmethods but you are right that they use the opposite by default.

--001a114428b89713de053bc48a5b--