Comments
You might be right, but don't forget about the wisdom of the crowd.
I hope these systems will get good commenting/rating systems which will help people make the right choices.
BTW: Pirum is also powering Symfony's pear channel
very nice work, I like how each project has a customized subdomain as well.
Although Pirum is nice, it is not as complete or as powerful as PEAR2_SimpleChannelServer (or scs) which is available either as a standalone app or as a plugin to Pyrus (see pear2.php.net) which is inches away from its first release. This is a PHP 5.3+ PEAR installer that is distributed in a single file, a phar archive, and has support for amazing stuff such as true package signing using OpenSSL signatures as well as automatic creation of package directory structure, automatic building of package.xml files, and the ability to create tar, tgz, tbz, zip, or phar archives in a 1-line command.
I'd also like to see a pearfarm plugin to pyrus, check the manual for how to do it at http://pear.php.net/manual/en/pyrus.plugins.php
Greg
Evert-
Thanks for the post on Pearfarm! I think yours is the first one.
@daniel - pear installs can't trash other installations AFAIK. I haven't actually tried to make 2 packages that send files to conflicting places to test this, but I'd hope that since PEAR *could* know which packages own which files, that it would prevent such a collision. It'd be a good thing to test, for sure. In any case, the canonical pearfarm install has each project's files in its own directory, so this shouldn't ever be a problem.
That said, the fact that it's hard to create & share a PEAR package is *not* a good thing, it makes it hard to share code, and without code sharing & easy peer review, the community progresses very slowly.
@greg - our lead server dev Scott Davis built a RESTful PEAR server from scratch. We got a lot of extra flexibility by doing this, so that we can start to do ratings and other things to help with package selection.
We didn't use pyrus as our basis since we wanted to avoid the 5.3 requirement. It would be great to have a pyrus plugin for pearfarm. The project is open-source, feel free to join the project and help us do that! The packaging code is factored out nicely, it shouldn't be terribly hard to do.
I'll also point out that pearfarm does use PKI and sign all packages. This is how we make it so easy to push packages to pearfarm from the command line. I suppose that we could expose the signatures on the website so that you could verify them on the download side. I'll have to think about the security considerations of that.
We just heard about pearhub.org today when we read this blog post. A few difference between our systems:
1. Pearfarm includes a spec for *building* packages. We don't just tarball your entire git repo. This also means that you can have your pearfarm packages include "executables". I don't see how you'd do that with pearhub.
2. Each pearfarm user gets his own channel, vs one giant shared channel. This was done for performance reasons and to eliminate the "who owns this package" problem. Also the pearfarm model allows multiple forks of a single project to all be hosted easily and conceptually in a similar way to how GitHub works.
Thanks again for the post!
Alan
Great review - I think you got it summed up pretty well. Although I feel inclined to add that the reason why pearhub doesn't offer any tools is because you don't need any tools. I deliberately built pearhub so that everything can be managed from the web interface. The intention is to make things as simple as possible. Actually, once you have registered your project, you never need to visit the site again - everything runs on autopilot.
I would be interested to know the reasoning behind your preference for pearfarm over pearhub?
Other than that, Alan has contacted me over mail already, so we'll see if there is reason in combining our efforts into one site.
