Many developers currently employ a technique known as ‘component based software development.’ Component based software development is a development style in which the developer has a buffet of libraries to use, and chooses components or libraries for required functionality and writes a small amount of glue to hold all these components together. When these components are easily accessible, installable, and upgradable, the development lifecycle is vastly improved. In the PHP world, this means the components are available through a PHP Extension and Application Repository (PEAR)-compatible channel, and they are installable using the PEAR installer or Pyrus. Historically, the libraries installed would be closely tied to the machine they were installed on, but with Pyrus and the PEAR2 standards this is no longer the case. I’d like to share how we manage vendor libraries in many of our projects at the University of Nebraska-Lincoln.

Typically your project might include a vendor or lib directory, which contains external libraries for your current project. In some cases this directory is outside of the current project, and stored in one location on the system, or it is included in the project directory and committed to a version control system. The advantages of committing the libraries to your repository is that every developer can get up and running quickly with just a checkout or clone, and these external dependencies can be tracked along with your own files.

Pyrus, the next generation installer from PEAR, is a self-contained .phar file that requires no complex setup. Pyrus can also create self-contained registries of installed packages, which can be committed to a repository, moved around your filesystem, or moved to other machines. This makes the Pyrus installer an ideal candidate for managing vendor libraries and external components. (Download pyrus.phar here)

Ok, back to our project, and how Pyrus can help us.

Here’s a typical application layout -
src/
data/
www/
vendor/

In the vendor directory you would place your Zend Framework files, various PEAR packages, Doctrine etc. With Pyrus, all those external components can be installed locally, and when a new upgrade is available, anyone on your team can upgrade the dependency with a one-line command and commit that to the repository. On the next svn up or pull, every developer is up to date with the latest versions. Developers have been doing this for years, but the difference is that all the libraries are easily upgraded and dependencies are handled automatically.

Here’s how to use Pyrus to install Doctrine into a vendor directory -

wget http://pear2.php.net/pyrus.phar
php pyrus.phar ./vendor set bin_dir ./vendor/bin
php pyrus.phar ./vendor install pear.doctrine-project.org/DoctrineDBAL-beta

Each command in detail:

1. Grab the latest version of Pyrus.
2. Set the bin_dir to vendor/bin so the Doctrine scripts are also included in our self-contained repository. Note: Because binaries are machine specific and need to be in system paths, scripts will be installed alongside your PHP executable, unless you specify another location.
3. Next we install the DoctrineDBAL package.

The Doctrine DBAL library is now installed in vendor/php/Doctrine. When a new version comes out, you can simply run `php pyrus.phar ./vendor upgrade doctrine/DoctrineDBAL`

Find out more at http://pear2.php.net/

• Previous Entry: SVN Switch and Relocate Everything
• Next Entry: Fail Early