Wishing For A PEAR Channel Aggregator? Yes, Please!
Image via Wikipedia
There are a few things many PHP developers should be familiar with. We should be familiar with PEAR packages. We should be familiar with the PEAR installer. More and more of us actually are getting familiar with running PEAR channels. The problem that some of us have, like me, is that we're working against an architecture which focuses on the central PEAR repository. It's the elephant in the room, so to speak, and we spend year after year working around or completely ignoring it.
While I do criticise PEAR through this statement, that would be missing the point. PEAR is a story of two parts - the distribution mechanism using the PEAR installer and PEAR channels, and the centralised package repository. The problem is splitting the two, and I don't believe the PEAR group (along with the rest of us) have really considered that which is a shame. As Till Klampaeckel recently stated, a€oPEAR packages are not as easy to use as some code you copy-pasted off the Zend devzone or phpclasses. While I agree, that we should try to make it just as easy, it's just not one [of] PEAR's goals right now.a€¯.
That kind of sums up my issues with PEAR as a distribution mechanism - it's not as easy as it could be and it really ought to be a primary goal. It's nota€¦ PEAR obviously treats its own package repository as an elite citizen. You don't need to discover its channel, or use a channel prefix, or go consulting Google to find something useful (it has a neat categorised package listing). No other PEAR channel set up independently has those advantages and the extra steps can't compete with a simple download from a website. To install from another channel, you need to go search Google for a suitable library, check if it even has a PEAR channel, find the channel URI, guess the channel prefix - and then finally install something. Since channel discovery is probably not automatically performed (by default), dependency resolution can lead to more pain. This assumes hosting a PEAR channel is easy (which it is given the recent explosion of them using sane channel hosting tools like Pirum). Maybe that's our trigger - PEAR channels are easy now. Suddenly, all the libraries I use are, or will be, hosted on a PEAR channel. Even Zend Framework 2.0 is heading to PEAR split by component. It's fantastic!
Since we seem to like blaming the PEAR Group, and getting that ball kicked back to us, it's time we did something useful. We've spent too much time ignoring PEAR as we grew apart from it with our frameworks, standalone libraries and custom plugin architectures. We're making life harder for ourselves in doing so. Stuart Herbert has posted a short article to gather requirements for a Pear Channel Aggregator. I strongly suggest that interested PHP programmers drop by and add a comment with some suggestions/feedback. Let's get this thing moving forward!
Once that article went up, we started seeing that people are out there working on the problem. I don't see any of them as being a final solution, and God forbid we just adopt a half-measure for some limited subset of requirements. It would be far preferable, if not essential, to see a complete solid solution meeting everyone's varied requirements. There's no excuse not to. Either we want a robust complete solution or we don't.
As to the concept of a chann
Truncated by Planet PHP, read more at the original (another 3490 bytes)