PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

How Would You Engineer A PEAR2/Pyrus Distribution Architecture?

Note: This article was originally published at Planet PHP on 19 April 7440.
Planet PHP


Image via Wikipedia

I was recently accused on the Zend Framework Contributors mailing list of having aostrong feelingsa towards Pyrus (i.e. the PEAR Group's Installer/Packager for PEAR2) and not in a positive way. It's a fair description. PEAR is, putting it lightly, a very old architecture which makes it very resistant to change. With the idea of PEAR2 and Pyrus, I had hoped to see a renewal - the advancement of a PEAR architecture for the 21st Century. Instead, and this is just my opinion, PEAR2/Pyrus were a relatively simple iteration on a very old theme.

A Ranting We Shall Go

Now, I may be biased since I gave up on PEAR becoming PHP's core distribution mechanism after I found myself using alternative strategies for hosting and deployment. This is not to say PEAR is not useful for everyone. It is - just not in my specific case when developing/testing/deploying applications. It still remains a good distribution means regardless by virtue of its ubiquitous installation with PHP.

I surprised even myself, however, with my vehement outcry over the idea of adopting Pyrus as Zend Framework 2as package distribution method, lambasting both it and the PEAR concept of distribution in equal measures while piling up questions on Pyrus' status (currently released in alpha) and suitability in the near term. That thread showed a fairly divided sentiment. Once I jokingly threatened to mow down my zombified colleagues with a minigun, I figured it was time to go forth and rant (miniguns are too expensive for these recessionary times).

If the PEAR ecosystem has a failing, it is one of staggered evolution. Over time it has picked up additional features tacked on top of a base model. The classic example is the use of Channels (to support multiple repositories) that has more recently prompted calls for the use of a Channel Aggregator to avoid the use cost in locally managing a channel registry or even hosting a Channel. This is the way of many PEAR features. They each do something incredibly useful but do it in a way that has many developers looking for a better approach - usually to discover the better approach requires breaking compatibility.

My vehemence in the afore mentioned mailing list was down to a simple case of disappointment. We all deal with PEAR because we have it, we know it, and have done so for years. Seeing PEAR2 and Pyrus take the incremental improvement route without apparently doing anything to change the core experience seemedapointless. It improved a lot of what PEAR already did without actually doing very much different. All the same advantages, disadvantages, features and lack thereof were present and accounted for with a handful of nice headline changes (e.g. we now have package signing capability). What exactly was the purpose of rewriting the entire toolchain if not to seize the opportunity to answer the accusations of those who doubt PEAR is even relevant these days - by making it the single most relevant development in PHP today?

One Possible Path Forward

Since this is a brain dump post, as much to gather my own throughts in one place as anything else, feel free to call me bat shit crazy. There are days even I think that. Below I've raised what I perceive as problems in the PEAR/Pyrus system, obviously from a personal perspective, and possible solutions under the categories of Packaging, Distribution, Installation and Usage. I've tried to avoid getting into technical details - broad strokes will suffice for now. For your sanity, only the Packaging and Distribution areas are presented today. I will add a similar post for Installation and Usage later in the week. First one to mention aoTL:DRa

Truncated by Planet PHP, read more at the original (another 17493 bytes)