3

It seems to me that PEAR is picking up steam again, at least as a distribution mechanism. With the availability of simple PEAR channel servers that are actually simple (e.g. Pirum) it seems many projects are moving towards PEAR as a distribution mechanism. Some examples include PHPUnit, Phing, Symfony2, Doctrine2, etcetera. However, I am running into serious trouble trying to manage this.

I don't want to use a single system-wide PEAR anymore. I have dozens of websites on a single server, all using various libraries distributed through PEAR channels. Some of these websites are old. Some have conflicting dependencies. I don't want to have to check 30+ sites every time some new package version comes along. But, at the same time I don't want to be stuck on some ancient package version when I am working on a new site.

I have been breaking me head over this for quite some time now. PEAR as a distribution mechanism seems to be completely unsuited for any kind of setup where multiple sites run on the same server. It appears to be impossible to maintain many parallel PEAR repositories on a single machine, or check PEAR repositories into version control.

A lot of problems appear to be caused because PEAR replaces certain paths in PHP files on installation time, instead of resolving them at runtime. For example, Phing wants to know where the PEAR data_dir is. When the file phing/Phing.php is installed, the string @data_dir@ is replaced by whatever the data_dir is at that time. But that makes it impossible to move it or keep it under version control.

I know Pyrus and PEAR2 are supposed to solve a lot of problems, but they appear not to be viable options at this point. Many of my sites depend on PEAR packages not ported to PEAR2. And Pyrus is being very fussy regarding PEAR channel implementations, making many PEAR1 channels unusable with Pyrex (for example, PHPUnit refuses to install with Pyrus because of a misconfiguration over at eZcomponents.org).

So, with a future that appears to bring ever more packages through PEAR channels, how can I manage all those dependencies for all my websites? I can't be the only one suffering from this. Someone smarter than me must have already solved this issue.

EDIT: So far I found Pearanha. Basically it generates a custom PEAR for your specific project. This would need to be integrated in a build step though, since it doesn't make the PEAR repositories moveable.

pear-switch promises to make a PEAR repository moveable but it does not work. It is hard-coded to deal with the registry files and the hard-coded include path in pearcmd.php, but it does not handle any other path that was replaced into the PHP files during installation.

Sander Marechal
  • 289
  • 4
  • 11

2 Answers2

2

Use Pyrus, the next-gen pear installer and follow the instructions in Using Pyrus To Manage PEAR Installable Vendor Libs.

cweiske
  • 781
  • 1
  • 13
  • 36
  • I already tried Pyrus (see my question). It isn't working for me because it's much more strict about channel implementations than the old PEAR installer. So, many packages normally installable by PEAR are currently not (yet) installable through Pyrus. PHPUnit for example (because it depends on something from eZ Components and eZ broke their channel and refuse to fix it). – Sander Marechal Jul 07 '11 at 11:12
  • serverfault.com may not be the best place to ask question regards sf2 and since there isn't yet any efficient way to receive support with symfony 2 I think the following proposal is a very good idea! - [A new Q&A site for symfony2](http://area51.stackexchange.com/proposals/36634/symfony2) - Please join & spread the word! – Xuni Nov 20 '11 at 10:40
2

Christian is right. Pyrus is the best way to manage a local registry of PEAR-installable vendor dependencies for your application.

I think the issues you're running into are caused by poorly implemented packages/channels, not issues specific to pyrus, or the method.

Pyrus does not allow the user to customize the path to the data_dir for example, therefore the installation can be self-contained and packages can rely on where data_dir files are located.

For example, a vendor dir using the new registry directory layout looks like:

data   <--- role = data
docs   <--- role = doc
php    <--- role = php
tests  <--- role = test
www    <--- role = www

Instead of a @data_dir@ replacement, use a path based on the current directory, such as

dirname(__DIR__).'/data/pear.channel.com/PackageName/datafile';

Developers that distribute PEAR-installable libraries should modify their packages to use the newer registry directory layout standards, instead of relying on path replacements that tie the installation to a specific machine.

saltybeagle
  • 141
  • 2
  • I know. I'd *love* to use Pyrus. But the fact remains that there are quite a few broken channels out there that do not work with Pyrus (but do with with the old PEAR installer) and that there are many packages that use `@data_dir@` replacement. So, this makes Pyrus unusable *for me* at this moment. Maybe in a year or so, maybe longer. But I have clients that I build websites for *now*. – Sander Marechal Jul 10 '11 at 21:23
  • I currently use pyrus for managing all my pear-installable vendor libraries for my applications, and haven't run into that many issues. You could help out yourself and quite a few others if you contacted the maintainers of these PEAR channels and encouraged them to make their channels function correctly. – saltybeagle Jul 11 '11 at 02:33
  • Oh, I do that too. Don't worry :-) – Sander Marechal Jul 11 '11 at 04:05