The Future of PHP and PEAR

Standard
This post is over 11 years old and is probably out of date.

It has been decided by those “higher” powers that PHP 6 will not feature PEAR bundled.

Update: What has actually been decided, is that PEAR such as it is, at 1.3, with its numerous problems and issues will not be included in PHP 6.

First off, I’d like to point out that the PHP 6 development branch was only created about a week ago, and we’re not likely to see any sort of a release for at least a year (if PHP 5.1 and the scope of changes needed for Unicode are any indication) – how can this decision be made at this point?

There are several points I want to make directed at those “higher” powers, I don’t expect anything to change, but who knows.

There have been numerous pushes to move more and more non-core extensions to PECL, with some calling for all non-core
extensions to be moved there and all available for install as shared modules. Without a working PEAR installer in PHP 6, this idea
can be thrown right out of the window. Perhaps this is why it was done?

In the past year Greg Beaver has all but re-written PEAR from scratch. Pretty much on his own, he has single-handedly transformed a rather soggy 1.3 release into a much more featureful, robust tool which benefits not only PEAR/PECL but anyone who wishes to release PHP code or PHP extensions and have it easily installed. He has written literally hundreds of tests for PEAR 1.4, where 1.3 has none. He has followed a very sane release cycle and is approaching a Beta state – though he is currently hampered by his current state of flux with a cross-country move.

One of the major gripes about PEAR has been its inability to install PECL modules. I have seen griping, bitching, moaning, put downs and worse from some of the largest names in PHP. Especially among the PECLers. Yes, I understand you’re frustrated, but how can you expect a non-internals developer to write a tool that works flawlessly with so little input from those who are writing the packages its supposed to install? I mean, seriously, we’re talking – in my opinion – several of the brightest minds in PHP today and you can’t spare a few hours to put your talents into the PEAR installer?

Now, I understand the desire to make the packing of releases as painless as possible, we’re all volunteers. We all want users to keep their PEAR installs fresh, we don’t want to QA the package releases that make it into PHP releases. These are all valid concerns, and I agree with most of them. But how about committing to working out a solution which will simply install the latest stable PEAR installer from pear.php.net and thats it? With the new REST web services in place, theres nothing more than a little XML parsing neccessary to grab the tarball, then to just untar it and move the files about… theres no complex XML-RPC etc to get in the way here.

To summarize, I don’t think the decision was taken lightly, but it was definately taken prematurely. Nothing this drastic which affects something which I consider integral to PHPs continued success should have been done till a) there had been some community discussion b) A solid plan is formed for a replacement. README.PEAR is not enough.

– Davey