Bill Shupp Software engineer, photographer, musician, space geek

24Dec/104

GitHub Pages + Pirum = Easy PEAR Channel

I prefer managing my non-PEAR PHP dependencies (such as Zend Framework and PHPUnit) through PEAR channels when possible.  It's much easier to manage component installation, upgrades, etc..  Managing and hosting a PEAR channel (using the Chiara_PEAR_Server) is not always that simple, and can add too much overhead for small projects.  I like how Zend Framework leveraged google code to host its PEAR channel, and was able to update it simply through pushing to SVN, avoiding a web interface.  Since I've been accumulating some components recently that really don't fit into pear.php.net, I figured it was time set up a PEAR channel for distributing them, but didn't want to host it myself or have to use a web interface.   Turns out, it's really easy to do now.

Hosting using GitHub Pages

Since I prefer GitHub to Google Code for hosting my open source repositories, I decided to take a look at their new Pages feature for project web hosting.  It's super easy to set up.  You can host content at http://username.github.com by creating a repository username.github.com (master branch), and can also host project related content at http://username.github.com/project by creating a top level gh-pages branch in the project.  I was up and running in minutes.  See here for specific instructions on setting it up.

PEAR Channel Serving with Pirum

I wasn't sure what the ZF guys were using to manage their channel, so I started by looking at PEAR2's SimpleChannelServer.  While it looks promising, and you can even manage it directly from pyrus, I ran into enough errors that I thought I'd take a look Pirum, another simple channel server written by the Symfony project maintainer.  It worked for me right out of the box.  Setup was as simple as:


pear channel-discover pear.pirum-project.org
pear install pirum/Pirum
cd ~/git/pirum
# create pirum.xml file
pirum build .
# commit changes and push to github

So now releases through my PEAR channel look like this:


# update PEAR package.xml, then run:
pear package
cd ~/git/pirum
pirum add . ~/git/deneb/Deneb-0.3.0.tgz
# commit changes and push to github

Now I've got an easily managed PEAR Channel that I don't have to host:  http://shupp.github.com/pirum

Comments (4) Trackbacks (0)
  1. This looks a lot harder than pearfarm or pearhub. Why don’t you use these simple and scalable tools instead?

  2. Alan: This article is aimed at people who prefer to manage their own PEAR channel. I agree that it’s less steps to use one of the services you mention, so it’s certainly simpler. But, given the current usage of these projects, I don’t think anyone can speak to their scalability yet.

    I also take issue with the notion that this is at all “hard”. If a developer thinks this is too hard to do, I probably don’t want to use their software.

    That being said, if you don’t have the need to run your own channel, my recommendation is always to try and submit to PEAR if possible. The proposal process offers peer review, coding style consistency, and the broadest reach for PEAR distribution and collaboration. If your project doesn’t fit into PEAR for some reason, then perhaps pearfarm or pearhub would be a good choice.

  3. The reason I had commented is that someone tweeted me a link to your post asking to compare it to pearfarm/pearhub. And since your post doesn’t mention either of those, I thought maybe you weren’t aware of them.

    Before pirum and the symfony project you mention, it was incredibly painful to set up a channel server. Even with recent projects making it easier, it’s still not trivial. While I agree that anyone that wants to produce a PEAR package *could* get one up and running, the question is WHY would you want to?

    I personally see no advantage to wasting time setting up even the simplest of servers. Having lots of packages centralized has many benefits, including time efficiency, better discoverability, economies of scale, etc etc.

    Adding a project to PEAR itself is a months-long endeavor that puts you at the whim of a group of people unrelated to your project, and I see it as 100% useless bureaucracy. There are plenty of ways to judge code quality via peer review, coding style, etc without having a small group of people doing that for all projects.

    The PHP community really needs something like pearfarm or pearhub to succeed. I strongly believe (and have evidence to back it up, just see rubygems.org) that such an infrastructure can be incredibly productive for the community.

  4. There are many reasons one might want to run their own pear channel, including the following I have directly experienced:

    1) Internal distribution of components across projects (we did this at Digg, where some code could not be released publicly)
    2) When you have the need to not rely on a 3rd party for availability of the channel

    I strongly disagree with your claim that the PEAR proposal process is “100% useless bureaucracy” and that you are “at the whim of people unrelated to your project”. ALL PEAR developers have the opportunity to comment and vote on proposals. The point of the proposal process is to promote and ensure best practices (like code quality, code style consistency) across ALL libraries (not just yours). It’s also intended to foster collaboration on projects, rather than have 15 different HTTP_Request implementations to have to sort through. Your claim that it is a “months long endeavor” is not true. Have you even submitted a proposal? (I couldn’t find an account for you). While some proposals do take months, it’s up to the person proposing to move it through. My first package (Net_Vpopmaild) went through the whole process in 2 weeks, and it greatly improved the quality of code from where it started.

    I have no problem with projects like pearfarm and pearhub, and agree that they can be productive for the community. But I do think there is value in PEAR and its proposal process, and don’t like to see misinformation spread about it.


Leave a comment

No trackbacks yet.