Re: [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

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’ve 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’s 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’t get me wrong, composer was programmer-heaven-sent and I love using it but if somebody has a better idea I don’t want core to provide relative competitive advantage just because it’s 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’s 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

Attachment: [application/pgp-signature] Message signed with OpenPGP using GPGMail signature.asc