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

Also, just wanted to say: As a former fairly major contributor to PEAR (see: http://pear.php.net/user/davey) I understand that PEAR has a special place in the heart of many old-school PHP developers — but I believe that the community has spoken, through lack of action on PEARs part, and the rapid adoption of composer on the general communities part. We should probably also have some conversations about actually sunsetting the PEAR and PECL sites and deprovisioning those resources. But that's a whole other conversation ;) - Davey On Fri, Sep 2, 2016 at 12:32 PM, Davey Shafik <me@daveyshafik.com> wrote:

On Fri, Sep 2, 2016 at 2:33 PM Davey Shafik <me@daveyshafik.com> wrote:

Will composer/pickle address the unsolved PHP compatibility issue that makes pecl a pain following the PHP 7 release?

On Fri, Sep 2, 2016 at 1:33 PM Davey Shafik <me@daveyshafik.com> wrote:

+1 A bunch of years back I tried contributing to a handful of PEAR_Auth packages and the 'maintainer' rejected them all on the basis of the PEAR library was mothballed with recommendation to use ZendFrameworks Auth packages. I know at least where I work we're migrating everything off of PEAR in deference to community maintained packages in composer. The only negative I could possibly see is a lack of a central, for lack of a better term, authority of PHP preferred packages for the multitude of services PEAR offers. But I don't necessarily see this as a major issue with the multitude of frameworks&microframeworks that modularize all their bits and places like composer/packagist maintaining a growing list of packages. I guess PEAR served that purpose years ago in a more isolated PHP source environment, rather than today where it's heavily tracked and distributed. Cheers

On Fri, Sep 2, 2016 at 1:32 PM, Davey Shafik <me@daveyshafik.com> wrote:

I like the idea, my only concern is that pickle hasn't been committed to master in many months and the build is listed as failing. In fact the last release (v0.4 from what I can tell) also shows the build as failing?

On 02/09/16 20:32, Davey Shafik wrote:

Is Composer really all there is? I'm looking at the problems projects like tiki have with trying to keep composer working in an active project, and other projects have just as many bug reports of composer having failed again! Keeping the right combination of versions of third party libraries may be what it is intended to do, but it does not seem to achieve it. I make no bones about the fact that I don't like the way composer works, and warnings about "You are running composer with xdebug enabled. This has a major impact on runtime performance." Trying to set up an environment where composer only exists for PHP7 so it does not affect the legacy systems seems equally problematic. And Packagist has some many cross competing packages that it does not make providing a set of 'supported' php libraries at all feasible? I've just tried to get owncloud running again. I had it working fine in PHP5.3 days, but at some point an upgrade failed and while I managed to keep it working for a bit, it was not stable. I tries again last year but it was taking too long, so I switched tack this year, installed clean from the distribution and while it sort of installed it will not run and add the very thing I'm trying to restore, the mail package. I SUSPECT it needs composer somewhere under the hood, but getting white screen failures and no decent errors it's gone in the bin again. If composer is to replace PEAR then it needs to be properly supported INSIDE PHP as PEAR is and give the sort of support that PEAR currently provides to new users. Linux distributions once again provide their own views on how to combine composer and the other similar package managers for javascript, python and the like with their own manager and the situation is simply a mess! I've half a dozen package managers listed across the whole web framework base, and composer is not top of the list.

On 02/09/2016 20:32, Davey Shafik wrote:

Hi Davey, I think this is a sensible idea. It basically accepts the reality that PEAR is no longer the main place new users of PHP should look for 3rd-party code. Thinking about the responses so far, I thought it would be useful to enumerate just what PEAR is, and what is being proposed for removal. It might even be worth adding a version of this to the RFC, in case it reaches a wider audience who won't see this discussion. As I understand it, PEAR is: A1) A command-line package management tool for installing and updating packages of PHP code over the Internet. A2) A curated default "channel" for the package management tool, at pear.php.net A3) The coding style guidelines for publishing on that channel A4) An ecosystem of packages built to those guidelines While PECL is: B1) A related command-line tool for managing extensions to PHP itself. B2) A default channel for the extension management tool, at pecl.php.net The command-line tools (A1 and B1 above) are currently distributed with PHP by default, and this is what we are looking to deprecate. Composer is the common choice to fill the role of A1, and "pickle" is being proposed as the official replacement for B1. Everything else will still be there, including the ability to download the tools, probably through your OS or stack's package management system. As to the rest, a few rambling thoughts: - There is no single replacement for pear.php.net. packagist.org partially fulfils job A2, but it is a marketplace, not a curated channel, and it doesn't do anything to standardise style (A3) or interoperability (A4). PHP-FIG is one attempt to fill that standardisation; it's entirely voluntary, and entirely separate from php.net, but it's not like anyone was ever forced to publish on pear.php.net. - pear.php.net is technically only one "channel" compatible with the tool, but I'm not sure how many others are out there in practice. As a random example, I know that Swift Mailer used to maintain a PEAR channel, but checking back it is now officially unsupported: http://pear.swiftmailer.org/ - On the flip side, many of the packages that are published on pear.php.net are also available on packagist.org for installation with composer, either in this list https://packagist.org/packages/pear/ or in unofficial forks. - The PEAR coding style would probably be considered "out of date" by a lot of PHP devs. That's partly a matter of fashion, but also a natural consequence of it predating certain language features - autoloading, namespaces, etc - which people want to take advantage of. - There is a "PEAR2" consisting of the "pyrus" tool, and pear2.php.net. It appears to be basically abandoned, although it is still prominently linked from pear.php.net. I assume pyrus never made into the default distribution of PHP? Regards,

On Sat, Sep 3, 2016 at 4:32 AM, Davey Shafik <me@daveyshafik.com> wrote:

+1

On 9/2/2016 9:32 PM, Davey Shafik wrote:

Clearly +1

On Fri, 2 Sep 2016 at 20:33 Davey Shafik <me@daveyshafik.com> wrote:

I'm -1 on bundling composer and/or pickle. If people want this software it is trivial to obtain, and is far easier to keep up to date if it is managed out of band.

On 9/2/16 3:32 PM, Davey Shafik wrote:

Yes! It's good for the software (and its users) if it is maintained and contributed to using _currently_prevailing_conventions_ in f/oss.

Not so sure about this. While composer seems to be the currently prevailing convention for PHP deps right now (I don't know pickle), each project could instead have its own installation guide containing whatever makes sense (perhaps even something Windows-based for Tony). The PHP project could usefully maintain a policy on installation for the projects it has fingers in (PHP's a style guide to installation guides). But I don't think it helps to *dictate* those tools and methods and tie them to PHP releases. Just liberate the code and *encourage* uniform practices but let them evolve with some autonomy. Tom

Hi!

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. Pickle main README says: Pickle is a new PHP extension installer. It is based on Composer and the plan is to get Composer to fully support it. 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?

Add in which meaning? Distribute composer package with PHP source? Wouldn't that add maintenance load to keep it up-to-date? 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.

On 2 September 2016 at 20:32, Davey Shafik <me@daveyshafik.com> wrote:

Even if Pear and Pecl overlap and share code, it would be better to focus on the end-user capabilities and have separate RFCs for altering those capabilities, rather than just trying to do everything in one RFC. i.e. have: One RFC to deprecate then remove the ability to install Pear userland code modules. A second RFC to deprecate Pecl and optionally start using Pickle. Can you clarify one thing though - am I correct in that Pickle is completely userland code? So why does it need to be 'shipped' with PHP. Why can't it be a separate download? cheers Dan

Needs moar macros: https://travis-ci.org/mkoppanen/imagick/builds/150948947

On Fri, 2 Sep 2016, Davey Shafik wrote:

I don't think that question is phrased correctly. It is asking about PEAR, and *not* PECL. I don't think we should deprecate *anything*, until pickle is deemed stable, and all issues with it are resolved (if there are any). So instead of suggesting to deprecate something, perhaps it would be a better idea to add pickle first - and only *then* even begin to figure out whether it's better than "pecl" for installing PHP extensions. "At the same time, we'd like to include composer/pickle as optional (under build flags –with-composer and –with-pickle) for 7.2, then enabled by default in 7.3. " I don't think we should bundle composer, and also don't think it should be an optional install. If it's an add-on (action required to enable pickle), people won't do it, and nobody tests it - and continues to use "pecl", which allthough not ideal, does do the job excellently.

What are these issues with the "pecl" installation tool? The RFC has no mention of this. One of them could be that it gets very few maintenance, and it's a little bit of a pain to update. Anything new should at least solve that. That also means there need to be at least 3+ people that know it well enough to be able to update, maintain and roll out releases.

You can't really ship PHP without a way to install extensions though! And it should work also work out of the box, without any other tricks or steps to make it working. That means, not having to run "composer install" in order to get a working "pickle" tool. A phar might be an idea. All in all, I think it is premature to want to remove something, without fully understanding the replacement tool. So, the first step would be to *add* something, and not call for the removal of things. cheers, Derick

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 upgrading 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 of 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 listed 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 the 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 global requiring, but it's usually for support tools meant for use at the command 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:

On Fri, Sep 2, 2016 at 8:32 PM, Davey Shafik <me@daveyshafik.com> wrote:

Can pickle package the extension? That's basically the only thing that I use pecl for: $ pecl package (it creates tgz based on the info in package.xml) I guess it's something other ext devs that have got exts on PECL would like to have too... Cheers Jakub

On Friday, September 2, 2016, Davey Shafik <me@daveyshafik.com> wrote:

Yes please! +1 This would be another major step forward for the PHP ecosystem.

Regards, Mike

+1 on stabbing the PEAR installer from the source distribution. -1 on adding anything else. Composer is as easy to install separately as PEAR from their origin as well as from OS distributions these days. On a side note, we should look into evolving ext/phar to a plugin based system, not the hard coded foreign feature sink it currently is (with regards to compression and signing support at first, with the underlying file format being next). Cheers, Mike

Hi Davey, thanks for the proposal and excuse my rather longish reply already.

[...]

[...] 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

On 02/09/16 20:32, Davey Shafik wrote:

I've just been through an exercise to give PHP_CodeSniffer a go on my code base. I've not worried too much about that in the past since Eclipse in general flags style problems as well as simple errors. This is a package that SUSE does not support, so the current install path is just PEAR. I don't see packages like this as a library that my sites use. It is a stand alone tool ( and a command line one at that :) ) so how would loading that be managed if PEAR is not available? I had the problem having loaded the tool in finding the rule sets so that I could create one suitable for my own application. That is dictated by SUSE was was not quite where I expected it, so this may also be something that an alternative tool loader might be able to help with? Main reason for loading was to give some of the PSR rule checks a try to see just what affect they would have on the code, but I don't think this approach will help with the structural changes needed?