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, “PEAR 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.”.

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 not… 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!

Gathering Requirements For A PEAR Channel Aggregator

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 channel aggregator, I view it as a shift away from PEAR’s focus on a centralised repository to a focus on supporting and enabling an open decentralised system with one (or more) focal points. PEAR’s own channel should just be one among many. A channel aggregator should do away with channel prefixes, channel discovery, compulsory reliance on PEAR packaging/channel hosting (git is too popular to ignore), and support combining the package details from potentially hundreds of channels/git repos into one or more competing aggregators that offer easier lookup, rankings, user feedback, etc (baby steps obviously before we go nuts). Installing any package from any channel or supported git repo should only require hitting up a channel aggregator with its name – no other mucking around. It would become an ecosystem that is impossible to ignore and obvious to utilise for hosting and distribution, not simply of libraries but of components, plugins and anything that can be considered installable. I’m also being careful not to overly point at one aggregator – any decent decentralised system should be capable of supporting multiple nodes with indifference, working in tandem or not.

The other side of the problem is PEAR channel hosting and packaging. Hosting is easy. Setup Pirum and you’re ready to go. Packaging needs a better tool. A script that can accept a simple configuration file, build the package, and optionally include a cryptographic signature (because who are we kidding, we need the system to be secure). While building a robust system, overly relying on traditional PEAR distribution methods while the PEAR community has been slaving away on PEAR2 and Pyrus would be a tragedy. Do it right, or not at all. Ignoring all that work, if it proves useful, makes no sense. At the same time, allowing them to create limitations in the requirements would be a serious error.

Regardless, we really need the PEAR Group’s participation because, frankly, their input and support will make the difference between evolving PEAR distribution (with or without the existing PEAR efforts) with us to meet our needs, or sundering the community into two approaches that probably won’t be compatible.

I would hope that we’re capable of improving the entire infrastructure – not just one piece of it. Hopefully, with the assistance of our PEAR colleagues. And hopefully by avoiding segmentation of the overall community. If you’re working on pieces of the puzzle, I appeal to you to band together. Let’s not let fiefdoms derail what could be a massive boost to publishing code (not just libraries) online.

Gathering Requirements For A PEAR Channel Aggregator

In case you missed it the first time!

Note: Please ensure you post your comments to Stuart’s article rather than here. Thank you!

Pear Channel?

For the past few months, the ZF team has been playing with the idea of releasing ZF from a PEAR channel. Over the past 2 years, we have seen a few channels distributing ZF that have pop up here and there.. so that lead us to believe there is an itch that needs scratching.

The compelling reason against a PEAR channel is that, with ZF, there is nothing to “install”. Just pop ZF in your include_path and off you go. You could obtain ZF from SVN via export, checkout or externals tag.. or you could download from the website. A PEAR channel (until recently), didn’t make enough sense because copying files from one location to another was all it would be doing.

ZF Grows beyond Component Library

That is … until ZF 1.8 (coming soon to developers near you). With 1.8, Zend_Tool will be going into production. I’ve chatted (#zftalk.dev@freenode) about it, I’ve spoke about it (#zendcon08), and I’ve tweeted about it in recent months. But for those that don’t know, I can sum Zend_Tool up in 3 major aspects of functionality:

• Zend_Tool_Framework is a dispatch system. While Zend_Controller has the Front Controller and web model hammered down pretty good, Zend_Tool_Framework is an introspective dispatch system for exposing its capabilities via command line (cli), XML-RPC, SOAP, or any other [insert your remoting platform of choice here].
• Zend_Tool_Project is a profile driven system for managing project related resources and their relationships to one another, the ability to create them, remove them and alter them within the lifecycle of a projects development.
• Zend_Tool_CodeGenerator is an abstracted system for generating code, including but not limited to PHP. Plans are in the works for generating Apache configuration files, ini and xml configuration files… all wrapped up in an API that is natural and similar to the API’s you’ve already become accustom to inside ZF.

So, that said.. What does this have to do with the PEAR channel? ZF is moving from a library of “runtime components” into more of a holistic framework with capabilities of code-generation, scaffolding, and project management, which complicates the process of installation. PEAR installer is really good at installing code into an already running PHP stack, be it site wide or local. So, by delivering ZF through the PEAR channel, the complexity of installation is shifted off of the consumers and onto the delivery channel.

So what does “installing” mean? It means some elements of the package need to go into some pretty specific areas on your system for them to work correctly. For ZF, it means you will need to put zf.sh or zf.bat in your executable path, zf.php in the php_bin directory, and put the Zend Framework inside your include_path. If you’ve used tools like PHPUnit, PHPDoc, or some other framework, this type of “installation” should make sense to you. If not, go poke around you system after installation to better understand.

Details

So, onto the technical details. If you want to see what it can do, first discover and install:

(discover the zf channel)
/my/path# pear channel-discover pear.zfcampus.org

(install zf-devel)
/my/path# pear install zfcampus/zf-devel

(or for something stable)
/my/path# pear install zfcampus/zf

More information will be posted on http://pear.zfcampus.org as it becomes available (this includes other packages in the channel, and other releases like beta and alpha).

To see Zend_Tool in action:

/my/path# mkdir tmp; cd tmp;
/my/path/tmp# zf create project

Now, go explore the project that was created. In addition to that, you can also run “zf show profile” and it will generate a tree of your project. There will be more updates, and more providers available in the coming weeks to show off what we’ve been developing for Zend_Tool. Also keep Zend_Application in mind because as it formalizes, it will be the target of what we will be generating from Zend_Tool and the zf command line interface.

Details, Details, DETAILS!

Like mentioned previously, the pear channel is beta. What could be beta about it you ask? Well for one, the package and release plan that comes along with it. As of this writing, here is the plan:

• ZF Package
  • Stable (no version modifier)
    • source: tag
    • schedule: on tag
  • RC – Release Candidate
    • source: tag
    • schedule: on tag
  • Beta (beta)
    • source: branch of current release branch
    • schedule: weekly
    • version: current + 1 mini
  • Alpha (alpha)
    • source: trunk
    • schedule: weekly
    • version: current + 1 minor
  • Development (devel)
    • source: trunk patched with selected incubator components
      • maintained in a file in incubator (locally for now)
    • schedule: weekly (or on demand)
    • version: current + 1 minor
• ZF_Minimal Package
  • (scheme same as above)
  • Source modified
    • no tests
• ZF_Extras Package
  • planning
• ZF_Laboratory Package
  • planning
• ZF_Doc_Lang Package (maybe)
  • planning

This might get tweaked over time, but the idea is pretty solid. Stable comes from tags as well as release candidate (and patch releases if they exist, not mentioned here). Betas are considered the next mini release, and alphas the next minor release. Development is super developmental, as you can see as its cut from trunk with selected incubator components.

More details will be forthcoming as I’m sure there will be questions you might have that are in search of answers. Till then…

Happy ZF-ing!