Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95759
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain strojny.net from 46.4.40.248 cause and error)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4E95866D-63F6-46F1-8C70-4C958CD3EB49"; protocol="application/pgp-signature"; micalg=pgp-sha256
In-Reply-To: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
Date: Wed, 7 Sep 2016 18:55:13 +0200
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <3C8089C3-FF5D-42D5-94FC-9FE230AF7878@strojny.net>
References: <CANaX5nf5S6aS-ZaB=51qvXv+wbReGb2petPBDogTA+MNMHyysQ@mail.gmail.com>
To: Davey Shafik <me@daveyshafik.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
From: lars@strojny.net (Lars Strojny)

--Apple-Mail=_4E95866D-63F6-46F1-8C70-4C958CD3EB49
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Davey,

thanks for the proposal and excuse my rather longish reply already.

> On 02 Sep 2016, at 21:32, Davey Shafik <me@daveyshafik.com> wrote:
[...]
> 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.
[...]

Before discussing the proposal, I wanna go back one step and =
disaggregate the main use cases of what pear does so far (I simplified =
that a bit, but look at pear help on your own):

 - Install PHP extensions written in C/C++ through pecl and pecl.php.net
 - Install PHP libraries written in PHP through pear.php.net
 - Act as a version manager for both C and PHP based =
extensions/libraries
 - Package pecl packages for release

Probably less used (my guess!):
 - Building an RPM spec file from a PEAR package
 - Adding additional PEAR channels to install more dependencies than =
what is on pecl.php.net and pear.php.net
 - Signing packages
 - I=E2=80=99ve heard there might be a web interface somewhere but I =
have no idea about it :)

I believe out of those use cases there should only be two that are =
supported in core:

 1) Install PHP extensions written in C/C++ based on a global repository =
like pecl.php.net (or it=E2=80=99s successor)
 2) Tooling for maintaining such PHP extensions written in C/C++

Note: The second one could be solved in userland but I think for =
convenience reasons this should be supported by core.

For a healthy ecosystem we want to have alignment but also competition =
on central pieces of infrastructure like composer is. Don=E2=80=99t get =
me wrong, composer was programmer-heaven-sent and I love using it but if =
somebody has a better idea I don=E2=80=99t want core to provide relative =
competitive advantage just because it=E2=80=99s bundled. Maybe if PHP =
would not have shipped pear it would be long gone. Also I would argue =
that the lifecycle of a package management tool is different than the =
lifecycle of language, meaning that a package management needs more =
upgrades than the language so bundling doesn't really fit.

Having said that, I think we should offer an easy way to install =
composer in the core as a practical, convenient and realistic =
compromise. Something like php --composer-install that basically does =
curl getcomposer.org/composer.phar > /usr/local/bin/composer && chmod +x =
/usr/local/bin/composer. If we want to get fancy even a script that =
replaces itself with the content of getcomposer.org/composer.phar. This =
could also include a policy that we would include competing package =
managers if they proof a certain level of traction in the same way.

Now for pickle specifically: as I have never used it personally I have =
no way to judge it=E2=80=99s stability or defect rate. I would love to =
hear an opinion on that from people with more experience here. Also what =
about traction: looking at the commit history of the project, could some =
of the authors chime and provide some perspective on wether it's more or =
less done, what the development roadmap (if any) looks like and what =
would be caveats of including it.

cu,
Lars

--Apple-Mail=_4E95866D-63F6-46F1-8C70-4C958CD3EB49
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIVAwUBV9BGcSQPF+sCY6wHAQi1RA/7B4GrAmlWIyVTYBgQlTOR74giaqm7wZ4e
Y2BQvWix30fYpeC9qOX9i78touEZ/MZ+iketOPsykvpaZbHIjhQY/Mu9QNtGmbi/
AxiUAuaLpGYXHSueVWMMq5RMfjsFmmDIZsx6d87ubPGAvcBm+y+sRSW2f7KhU6SP
LOnaG4r87ntfO74ofZudNRHXrTJjypH+P5mJE5q2OjBddnKs+E632s2/MlzOGWN7
fYjvtF2cOZthfaPzI7IgPpylfoIpfXFLkebtQlL+8E9jdH3R3S78Z+fTCkpjrqvV
SsBepwlBaT1seB5kUtXWKx6fpzFDr4q7PDbUEEJOdpYPfyG1h8JBQBj5+veziJ/8
XVZkO3qAyv2S+/LJelQ03a8j4bj6Wolthf+LjOmJSoxJ3k0kf5wH80Fc4lx+iORR
0IAlx6FRzrX8RPi0Za9J0Gw4fucU0yATAMAB1nqL9QKI4oVQz2YJzgrC6exyjawr
2BNlAsJibS7mhgyoTaHw4tI9mupJW6fJbcVIpNKVgHu+YW09G4X1IHPQVxRNoPN7
NX5LFZEDYeBWcIUN1XulSKMXsashqM1nIdn5uVV5VO/yEIjc7woMzXDprwNUtZ/S
hFotTVgf1hK6amHV+XoRhOtg75RbXNC8ldWS9sIcVwKQ4rMYFzALht2fc0KQ5xKj
DMOMLbn7y/M=
=Xmrq
-----END PGP SIGNATURE-----

--Apple-Mail=_4E95866D-63F6-46F1-8C70-4C958CD3EB49--