Ok, Greg Beaver’s work on channels has resurrected my interest in PEAR. I am interested in providing WACT on a PEAR channel and I’d like to better integrate WACT with some PEAR packages. My primary concern is over the installation implications.
I didn’t find a “powered by PEAR” section on the PEAR website. Can anyone recommend some large, widely deployed end user oriented applications based on PEAR? I want to try going through the installation process in some challenging environments. I’m just trying to get a feel for best practices and potential problems with installing PEAR and applications that depend on PEAR.
Feed
Subscribe to this blog…
You could take a look at seagull – http://seagull.phpkitchen.com and Horde Project – http://www.horde.org . Both projects (the latter provides many projects build againts the same framework). Seagull for sure is available as the PEAR package – thats one of installation options.
If you’re looking for applications that are installed by PEAR, don’t look too hard. Up until 1.4, there wasn’t really any way to deal with application code in PEAR packages.
As for applications that depend on PEAR, the first that comes to mind is s9y.
Thanks, I am looking for applications that depend on PEAR.
Yawp is a foundation composed of PEAR components with some glue to make them interoperate. http://phpyawp.com/
YaWiki is based on Yawp. http://yawiki.com/
Hope this helps.
Incidentally, kind of funny that the idea of have a channel separate from PEAR is what has “ressurected [your] interest” in it. That we can have the benefits of the PEAR installer without the rest of the PEAR repository is, I think, a Very Good Thing. Perhaps PEAR Group should start thinking about being, not a code repository first, but a standards body first.
Paul M. Jones, that’s a very astute comment and echos my own thinking. Too bad the installer isn’t called pear-get.
I am also currently pondering how to best make my framework installable via the 1.4 installer. I currently bundle all PEAR code in my own library dir mainly so that I have more control over the code. This allows me to add ugly hacks or bug fixes when I need them rather than having to wait for the developer to fix and release. It also helps me circumvent any BC breaks that happen by accident now and then.
Now I really dont know how to best address this issue now. I could have a channel with my fixed packages and ask anyone who uses my framework to put my channel infront of the pear channel. This would let me then add fixed releases to my repository (probably using a fourth number as the version number, since PEAR regulations specify that only 3 numbers are allowed in a version name). But from then on no PEAR release is seen anymore .. right?
Is there a way to teach the pear installer that all I am releasing are fixed up versions of packages from another channel and that higher version numbers from the original repository get preference? That way if BC breaks or some other issues does occur I could quickly follow up with another release, but this is not really a good solution either. So I would probably just ver tightly specify my dependencies like works only with version 1.2.3.x (where .x can be omitted or where x denotes a number).
Lukas:
There is no secure way to allow channels to mimic other channels.
The best way to provide patched packages is to put them up as a static download and have the users pear install http://blah.example.com/Package-1.2.3.4.tgz
However, you can avoid the upgrade-breaking-BC issues via the tag in dependencies.
Of course, I am always eager to hear of new situations that can’t be solved by existing solutions, and will ponder this one. This is why PEAR 1.4.0 is still alpha even though the code is stable
Very good points about alternate package versions. I had not considered this issue at all.
Boots — that’s a very “apt” name.
Hi Jeff, am coming a bit late to your post. I disagree with Ryan King’s comment above, the PEAR installer prior to the current 1.4 version is perfectly capable of installing complex web apps, we’ve used it for Seagull for some time, taking inspiration from Greg’s own phpDocumentor which reveals many useful clues.
The main one is that you have to set data_dir to your web document root, so your app files are installed there, and calls to PEAR and other libs are made out to their default location, eg, /usr/local/lib/php. We’ve also modified some PEAR packages for our purposes, but have chosen to only override where these mods were necessary, so upgrades are quite seamless. Eg, we override the mysql driver for PEAR::DB, and use an installer hack to place the file ‘mysql_SGL.php’ in the same directory, so a small change to the dns loads our driver.
Looking forward, Greg’s implementation of subpackages, not very documented atm, is the perfect tool to allow a framework to load and install arbitrary modules or components (not libs). We’ve identified a few probs (such as the hard-coded calls to HTML_Template_IT in PEAR_Frontend_Web) but hope to be solving these soon, maybe even use a few WACT components