Re: PEAR infrastructure for package distribution?

On 7/26/05, Mario Salzer <xmilky@gmail.com> wrote: > I have an (unmeant) pet project with hundreds of PHP include scripts, > as shopflifted from phpclasses.org: > > http://fpc.berlios.de/ > > While parts of that code are of pretty low quality, I'm _considering_ > to set it up as PEAR-compatible download channel (for a few elected > packages) - but that with as little effort as possible, of course. > > My first question therefore is, if PEAR is really meant as vendor- > independent PHP package management system? The new channels feature > seems to suggest that, but right now still only official PEAR.php.net > packages are distributed this way. (apart from Horde maybe?) Pearified.net packages Smarty and other applications/libraries; Solar is also using PEAR for installation and package management. I think as PEAR 1.4.0 becomes stable, you will see more and more channels springing up. > While the PEAR manual contains useful notes for package authors, it > doesn't explain the required work for setting up channels all too > well. So I'm wondering if there is a premade PEAR channel package > available anywhere (for static tarballs at best). Are the relevant > parts from the PEAR.php.net website freely available from a CVS > repository or so? There are a number of independent resources on setting up PEAR_Server; googling for pear_server will yield results. Among them are: http://seagull.phpkitchen.com/docs/wakka.php?wakka=PearTutorials/SettingUpAChannelServer http://www.schlitt.info/applications/blog/index.php?/archives/308-Set-up-your-own-PEAR-channel.html > The current PEAR packages are (of course) structured into descriptive > subdirectories, as defined by the PEAR team and how it made most > sense for the currently existing classes. But how should independent > packages be mixed into there? > > Is it permissible to throw include scripts into the PEAR top level > directory if a more correct categorization is lacking: > -> require("some_random_class_name.php"); > Or should vendor subdirectories (like Java) be added if classes and > files could conflict with or disturb PEAR code? > -> include("com/vendor/module/package/Whatever.php"); I'm not sure that there are any hard and set rules for this. I think the rule of thumb would be that if a package of the same name exists, throw it in a subdirectory named after your PEAR channel; Pearified does this (all Pearified.net packages go into the Pearified/ subdirectory). If there's a common prefix, you may not need to -- Solar, for instance, uses the Solar_ prefix for all classes, and thus there are no naming conflicts. > The latter for me had the disadvantage, that it would require further > script patching and made everything incompatible with the original > projects (renaming a "dir_class" into "FPC_Files_Directory" e.g.). > > There is of course no way to convert *all* tarballs from FPC/PCO into > PEAR packages, but because there are still enough where it made sense, > I'd like to have this process automated as far as possible. (Because > packages are occassionally updated from upstream.) Then if this is the route you feel you should take, write a script that will do this for you automatically ;-) > PEAR_PackageFileManager seems to be the right tool (have only toyed > with it yet, though) - but has someone already prepared an easy to > use commandline tool ("tar2pear")? > I'm looking for something with a tiny bit more heuristics, like a > completed list of ->addRole() patterns, and standardized version > deducing/mangling (like converting "2005-07-21" into "5.07.21") from > directory names. The way PEAR_PackageFileManager works is that you create a script that sets up options for your package(s), and then run it. You should be able to do any processing you want to do as part of that script. Cheers! -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/