Nearly three months ago now I left Australia and moved to New Zealand. I was fortunate enough to essentially transfer within the company I work for, so it was reasonably painless (except for the 9 weeks of waiting for my boxes of stuff to get shipped).
The office here is significantly larger than the Australian office (being where the company started and all) and I’m really enjoying having lots of smart people around and getting to work on a much larger variety of projects.
Libravatar is an AGPL federated alternative for the Gravatar service, allowing domain holders to serve their own avatars for email and openid from their own infrastructure, rather than trusting external closed services. Francois will be presenting about it at OSCON. He has stickers.
One of the things we’re working on to make for better adoption of Libravatar is making sure there are libraries available for various languages so applications can incorporate it as easily as they can Gravatar (or easier!). I volunteered to have a crack at making a PEAR package.
I’d never done PEAR before. The documentation is somewhat obscure, but I found a good article on, of all places, Zend.com.
So that’s sweet. Write your class (in the correct file structure), copy and customise the makepackage.php file from the docs for PEAR_PackageFileManager2 (
pear install PEAR_PackageFileManager2), run
php makepackage.php make to generate the xml build instructions (which expire at midnight for fun!) and then simply
pear package. Voila, you made a PEAR package. Amazingly simple once you know how.
The next part, however, isn’t simple.
If you want your package to be in the Official PEAR Channel, you have to walk over some burning coals, hop through a ring of fire and some random other tribulations thrown in for good measure.
You may be tempted to have some documentation generated with phpdoc in your actual package. Because it’s useful and will make your stuff more usable. You can’t. The .css files don’t pass the PHP_CodeSniffer PEAR standards tests. It took me nearly a month to get a definitive answer on whether it was possible to keep them in.
The next part is the peer review. I first proposed the package about a month ago. I got some suggestions about style, some pointing at the coding standards and file structure, and a suggestion to depend on a PEAR package to do what a core php function does better. Because of php 5.2. Which is EOL’d. I refused the dependency for dependency sake suggestion. Because, lolwat?
What this review stage didn’t pick up was a handful of bugs that made the package not work right. They’ve been fixed.
Earlier this week I moved the proposal to the voting stage. Now, apparently, this is where the code review actually starts. So far I’ve had suggestions to… basically rewrite it, and dependency for dependency sake, again. This was stated as conditional for a +1 vote.
Well, I’ll see how it goes. I cannot see technical reasoning other than preference for the suggestions, and nor can others who are fed up with the PEAR proposal process just from watching me go through it. Even if it fails to get into the main PEAR channel, it’s not game over.
Back when I was looking for an answer as to whether I could keep the phpdoc generated documentation in the package, I asked a friend who is involved in the php community if she knew. She asked around for me, and the overwhelming response she got was that PEAR was out of fashion because of the politics, and to not bother. Given how other languages successfully manage to have extension management, and how predominant php is, it’s truly a crying shame.
The cpan library and pypi library have been available for a while now either as part of the gravatar library (cpan) or independently (pypi). PEAR doesn’t even offer a Gravatar library. Just sayin’!