Home / server / Questions / 287389
Accepted
Sander Marechal
Asked: 2011-07-06 05:50:59 +0800 CST

How to manage dependencies on PEAR packages

  • 772

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.

php dependencies pear

2 Answers

  1. Best Answer

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

    • 2

  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.

    • 2