Quo vadis PEAR?
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).
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
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
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
If you use git and happen to have a
.gitignore, pearfarm will add
.gitignoreto the package.xml as well.
pearfarm adds a
baseinstalldirattribute to the top most
<dir />entity. Assuming your package is
Foo_Barand you have
Foo/Bar.phpin 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 —
Does it work? Always
pear package-validatebefore you push!
Does it install correctly? Feel free to
pear install Package-x.y.z.tgzand check if the files installed ok (
pear list-files pearfarm.pearfarm.org/Package)
package.xmlcan have files with different roles, while the standard is
php, there's also
doc(for documentation) and
testfor tests. When the
package.xmlis generated from the
.spec, all files get
phpby 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
Changelog? Why yes, you can! The
package.xmlsupports it and it would be nice if PEAR Farm eventually displays it. Here's how (after
0.0.2 alpha 2010-01-29 bugfix in makeRequest() (curl), corrected endpoint 0.0.1 alpha 2010-01-27 initial release
Most of these things could be improved in
pearfarm. and i'm pretty sure they will. Eventually! :)
And that's all for this time. If you want to see my packages on the PEAR Farm, follow this link.