Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95639
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Mon, 5 Sep 2016 11:13:54 +0100 (BST)
To: Davey Shafik <me@daveyshafik.com>
cc: "internals@lists.php.net" <internals@lists.php.net>
In-Reply-To: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1609051104340.10693@whisky.home.derickrethans.nl>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1320653005-1473070434=:10693"
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
 composer/pickle
From: derick@php.net (Derick Rethans)

--8323329-1320653005-1473070434=:10693
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 2 Sep 2016, Davey Shafik wrote:

> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and=20
> remove in 8.0), as well as add composer/pickle (optional in 7.2,=20
> default in 7.3+) in their place.
>=20
> https://wiki.php.net/rfc/deprecate-pear-include-composer
>=20
> I highly recommend reading the twitter poll and accompanying thread at=20
> https://twitter.com/dshafik/status/756337267547832320

I don't think that question is phrased correctly. It is asking about=20
PEAR, and *not* PECL.=20

I don't think we should deprecate *anything*, until pickle is deemed=20
stable, and all issues with it are resolved (if there are any). So=20
instead of suggesting to deprecate something, perhaps it would be a=20
better idea to add pickle first - and only *then* even begin to figure=20
out whether it's better than "pecl" for installing PHP extensions.=20

"At the same time, we'd like to include composer/pickle as optional=20
(under build flags =E2=80=93with-composer and =E2=80=93with-pickle) for 7.2=
, then=20
enabled by default in 7.3. "

I don't think we should bundle composer, and also don't think it should=20
be an optional install. If it's an add-on (action required to enable=20
pickle), people won't do it, and nobody tests it - and continues to use=20
"pecl", which allthough not ideal, does do the job excellently.

> I believe that pickle solves the issues with regards to pecl, and have ru=
n
> the idea passed Jordi and Pierre. Both are fine with this RFC. :)

What are these issues with the "pecl" installation tool? The RFC has no=20
mention of this.=20

One of them could be that it gets very few maintenance, and it's a=20
little bit of a pain to update. Anything new should at least solve that.=20
That also means there need to be at least 3+ people that know it well=20
enough to be able to update, maintain and roll out releases.

> I understand that adding in composer/pickle is just setting us up for
> having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, s=
o
> I've proposed the voting reflect that some people will just want to
> deprecate/remove pear/pecl and not replace them at all.

You can't really ship PHP without a way to install extensions though!=20
And it should work also work out of the box, without any other tricks or=20
steps to make it working. That means, not having to run "composer=20
install" in order to get a working "pickle" tool. A phar might be an=20
idea.

All in all, I think it is premature to want to remove something, without=20
fully understanding the replacement tool. So, the first step would be to=20
*add* something, and not call for the removal of things.


cheers,
Derick
--8323329-1320653005-1473070434=:10693--