I use PEAR a lot. All my current work is based on PEAR libraries (only) and I create and deploy everything via PEAR. I think it's been two or three years since I started playing with PEAR extensively.
Because of that, I need quite a lot of PEAR repositories for development, testing, staging, live versions, etc. That's a quite a lot of repositories considering number of projects I work on.
I think it is a good practice to have one repository per project and per purpose. Although, for development purposes I usually use only one global repository with recent version of all packages I need. But testing, staging and especially live versions of my applications are in separate PEAR repositories.
Therefore, creation of new PEAR repository is sort of routine task for me.
I've tried quite a few ways of doing it, but here's the one I use mostly, because it's quick and safe way how to get new local PEAR repository in a few seconds.
Prerequisities
Linux box, some existing PEAR repository (usually system wide one), ssh in case I do installation on one of the servers and BASH.
Installation
Following shows installation of local PEAR repository into the 'pear' directory located in my home directory. Of course, it doesn't really matter where the repository is located. It's always question of purpose and demand.
First of all, let's create future home of the new PEAR repository:
mkdir ~/pear
Next step is to create configuration file of the PEAR. It's possible to do this in a few ways.
However, I use safest way, in terms of the version of the system wide PEAR. Let me explain. Usually system wide PEAR repositories on the Linux boxes are quite old (it really isn't something sysadmins upgrade a lot
), so usually I am not able to use the other ways of creating PEAR configuration file.
Just for the record, system wide version of PEAR in this case was 1.3.5.
Here's what I use:
pear -s -c ~/pear/.pearrc -d doc_dir=~/pear/docs -d ext_dir=~/pear/ext \
-d php_dir=~/pear/lib -d data_dir=~/pear/data -d test_dir=~/pear/tests \
-d cache_dir=~/pear/cache -d bin_dir=~/pear/bin
Previous command creates configuration file '~/pear/.pearrc' with all the paths set up as I want.
Sometimes, however, I change those path settings for testing purposes to see if my packages don't have any problems with different layout of PEAR directories.
I think, this is a very important part of the testing of packages, because what works with one directory layout, may not work with different one.
Now, I need to change directory to the new PEAR repository location:
cd ~/pear
The last thing is to firstly install Archive_Tar and Console_Getopt, packages that PEAR depends on, and then install PEAR itself:
pear -c ~/pear/.pearrc install Archive_Tar Console_Getopt
install ok: Console_Getopt 1.2
install ok: Archive_Tar 1.3.1
pear -c ~/pear/.pearrc install --nodeps PEAR
install ok: PEAR 1.4.9
./bin/pear -c .pearrc list
INSTALLED PACKAGES, CHANNEL PEAR.PHP.NET:
=========================================
PACKAGE VERSION STATE
Archive_Tar 1.3.1 stable
Console_Getopt 1.2 stable
PEAR 1.4.9 stable
Couple of notes to the previous.
- I used switch '-c' to tell system wide PEAR, that I want to install those new packages into the new PEAR.
- I installed firstly packages PEAR dependens on (Archive_Tar and Console_Getopt) and then I installed PEAR with '--nodeps' switch to prevent failing installation because of dependency on PEAR 1.3 serie.
- After successful installation, I ran './bin/pear -c .pearrc list'. So, I used newly installed pear binary and of course I told it to use my local configuration file.
- I skipped few lines of actual output to make listing more clear. So don't be surprised if you see more information on your screen. Also, how much output you can see on your screen depends on what verbosity level you have set up in your system wide pear. But this is slightly off topic
.
Conclusion
PEAR repositories can be installed in many ways. PEAR allows you to change repository's directory layout without any requirement for modification of the actual code and also it offers many ways how to do the same task. It is definitely not 'convention over configuration' model, so it may confuse not very experienced users. However, in my opinion, convention can be forced for simplicity sake.