To PEAR or not to PEAR — PEAR2 is taking a while and I sometimes think that everyone associated with PEAR is busy elsewhere. Since a little competition never hurt, I’m especially excited about these recent developments.

With the release of Pirum, I’m really excited to see two public PEAR channels that aim to make PEAR a standard to deploy and manage your applications and libraries. One is PEARhub and the other is PEAR Farm. I think I’m gonna stick with PEAR Farm for a while, so this blog entry focuses on things I noticed when I first played with it.

PEAR vs PEAR Farm

A lot of people mistake these new channels for the wrong thing. They think that this will eventually replace PEAR. I don’t think it will — ever.

While I really welcome the idea that people push PEAR’s channel for a standard to distribute apps and libraries (PHPUnit, ezComponents, Zend Framework, Symfony, etc.), it’s also very obvious that these open channels will never be the same.

For an idea of what I mean — take a look at open code repositories around the web and especially when it comes to PHP, it’s very obvious that while there’s a lot of code, most of it is utter crap. (There I said it!)

And no one wants to rely on it when reliability is an objective.

The PEAR Coding Standards were not invented because it’s so great to tell people how to write code. But a lot of people need this guidance. While they have a lot of ideas about how to implement a feature or a cool algorithm, their passion does not extend to test coverage or even little documentation. And that’s where these sometimes frowned upon coding standards come in handy because they ensure that the code in PEAR is maintainable — which is really just the tip of the ice berg for professional software engineers and I’ll save the rest for another blog post.

Let’s get to it

Regardless of the fact that there always only few steps, PEAR setups tend to not work for or look complicated to a lot of people. Here are a few tips on how to get started. We’ll assume pear itself is installed (apt-get install php-pear).

PEAR Farm

Instead of what is written in the FAQ - suggested steps to get started. ;-)

  • pear channel-discover pearfarm.pearfarm.org
  • pear install pearfarm.pearfarm.org/pearfarm-beta

Spec files and package.xml

The package.xml is a configuration file for the PEAR package. It’s pretty long, and since XML is so verbose, it’s a turn off to many. PEAR Farm suggests to create a spec instead, so it can create a package.xml for you. This is pretty convenient, but there are also a few gotchas.

  • pearfarm init (inside the code repo)

If you’re doing it for the first time, it will issue a warning about a configuration file being created — ignore it and move on.

Continue by editing the .spec file with description, summary, maintainer and whatever else is a suggested edit inside it.

Then, feel free create a package.xml:

  • pearfarm build

This will leave you with a package.xml file in the same directory. Mission accomplished!

Gotchas & Tricks

These are a few things you should edit before you pearfarm push:

  • If you use git and happen to have a .gitignore, pearfarm will add .gitignore to the package.xml as well.

  • pearfarm adds a baseinstalldir attribute to the top most <dir /> entity. Assuming your package is Foo_Bar and you have Foo/Bar.php in your repository, it would install into /usr/share/php/Foo_Bar/Foo/Bar.php, instead of Foo/Bar.php. I’d suggest you remove it and instead namespace in the package name right away — YourName_FooBar.

  • Does it work? Always pear package-validate before you push!

  • Does it install correctly? Feel free to pear install Package-x.y.z.tgz and check if the files installed ok (pear list-files pearfarm.pearfarm.org/Package)

  • A package.xml can have files with different roles, while the standard is php, there’s also doc (for documentation) and test for tests. When the package.xml is generated from the .spec, all files get php by default, that’s why I’d go through the list in <contents /> to double-check that all files have appropriate roles set.

  • Another thing to take care of (imho), would be <dependencies /> — something that could probably be automated, but otherwise read up about in the manual.

  • Need to rebuild the package from your updated package.xml? Use: pear package!

  • Changelog? Why yes, you can! The package.xml supports it and it would be nice if PEAR Farm eventually displays it. Here’s how (after <phprelease />):

Most of these things could be improved in pearfarm. and i’m pretty sure they will. Eventually! :)

The End

And that’s all for this time. If you want to see my packages on the PEAR Farm, follow this link.