Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95629
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <0b264e3e-ac31-35b3-083c-27adbb4ccd5e@gmail.com>
Date: Mon, 5 Sep 2016 12:25:26 +0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <3708EDBC-659C-4928-92F8-9E46E4A733EB@koalephant.com>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com> <0b264e3e-ac31-35b3-083c-27adbb4ccd5e@gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
From: php-lists@koalephant.com (Stephen Reay)


> On 5 Sep 2016, at 11:19, Stanislav Malyshev <smalyshev@gmail.com> =
wrote:
>=20
> Hi!
>=20
>> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and =
remove
>=20
> What would be achieved by this? I'm not sure about status of PEAR -
> frankly, didn't touch it for a long time - but if composer replaces =
most
> of it, it may be ok to remove by-default install of pear tools. Though
> I'm really not sure what "deprecating" means and what it's going to
> achieve.
>=20
> Pickle main README says:
>=20
> Pickle is a new PHP extension installer. It is based on Composer and =
the
> plan is to get Composer to fully support it.
>=20
> How is that plan going? I see the pull req it refers to still open,
> which means it is still not complete. Should it be completed before we
> recommend it as an only solution?
>=20
>> in 8.0), as well as add composer/pickle (optional in 7.2, default in =
7.3+)
>> in their place.
>=20
> Add in which meaning? Distribute composer package with PHP source?
> Wouldn't that add maintenance load to keep it up-to-date?
>=20
> If that means get some way to d/l newest stable composer, e.g. when
> installing php, that probably would be a great idea. Does not require
> removing stuff though.
>=20
>=20
> --=20
> Stas Malyshev
> smalyshev@gmail.com
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20


I think there is value in reducing the number of =E2=80=98bundled=E2=80=99=
 things, particularly given that Debian (and thus Ubuntu), Centos and OS =
X all distribute PEAR/PECL as a separate package. On the Linux distro's =
it=E2=80=99s a separate (but possibly =E2=80=9Crecommended=E2=80=9D by =
php-cli etc) package. On OSX there is =
`/usr/lib/install-pear-nozlib.phar`.

Unbundling from PHP itself then makes perfect sense to me - it=E2=80=99s =
effectively mirroring how PHP is actually distributed for a great number =
of environments already.

However, I find the concept of then adding in Composer/Pickle to be a =
very odd choice, and a poor one =E2=80=9Cpolitically=E2=80=9D.

As someone else said, bundling composer sounds like an official =
endorsement of PHP-FIG, which I suspect a number of people would have =
issues with.

On a purely technical level - it makes little sense. As demonstrated =
above, a decent number of environments are not going to ship it as an =
included tool anyway.