PEAR has a tendency to confuse people as the name is used interchangeably for the PEAR installer and for the PEAR repository at http://pear.php.net. This confusion naturally arises from the fact that the front page of pear.php.net says "PEAR is a framework and distribution system for reusable PHP components" but the PEAR installer's package name is "PEAR". In fact, PEAR is both a code repository and an installer; the two are linked inextricably by the fact that much of PEAR's strength is the ability to update a local installation from packages on a remote server over the Internet.
The PEAR package repository at pear.php.net is the official PEAR channel, and is the oldest PEAR channel, predating the concept of PEAR channels by five years. Many popular packages are distributed via pear.php.net such as HTML_QuickForm, DB_DataObject, MDB2, and PhpDocumentor. Most of the time, when people refer to "PEAR" in the abstract, one of the packages distributed at pear.php.net is what they are talking about.
The package repository at pear.php.net was established in 1999 by Stig Bakken and a few others to help fill in the gaps in PHP. PEAR's first usable release coincided with approximately PHP version 4.0.6. At this time, PEAR was designed as a framework, providing several base classes and an installer to manage them. The PEAR package provided two of the base classes, PEAR and System. The PEAR class, located in file PEAR.php was designed to provide basic error handling and a few other add-ons beyond what is available in PHP's internal trigger_error() error handling.
Several basic packages were designed to handle common tasks, such as DB for database-independent code, HTML_Form for HTML Forms, Log for basic logging, and this list expanded (to make a long story short) until the present day where there are 374 packages available from pear.php.net at the time of this chapter, and more on the way via pending proposals.
PEAR has had its share of woes since its rosy beginnings. PHP has evolved, and introduced several features that supersede the functionality provided by PEAR. For instance, the Exception class introduced in PHP 5.0.0 provides similar functionality to the PEAR_Error class, the PDO extension provides similar functionality to the DB package, and so on. In addition, as PEAR has grown, some problems in its initial design as a repository have surfaced and led to both minor and major crises.
Several good things have come out of these growing pains, including the efficient PEPr proposal system for proposing new packages, and a strong push towards both stability and innovation. Much of the push towards innovation is coming from external pressure due to the advent of new ideas from projects like SolarPHP, eZ components, Phing, Propel, Agavi, and the Zend Framework. However, one of the significant forces of innovation in PEAR is the PEAR installer itself, specifically with the new features found in version 1.4.0 and newer.
One of the crucial new features in the newer versions of the PEAR installer is PEAR channels. A PEAR channel is simply a server that provides packages like pear.php.net, and also provides special web services that enable the PEAR installer to communicate with the server; channels are covered in detail in Chapter 4.
Most books that discuss PEAR spend a great deal of time on using popular packages from the PEAR repository (http://pear.php.net) such as DB (http://pear.php.net/DB) or HTML_QuickForm (http://pear.php.net/HTML_QuickForm). This book takes a different route, instead focusing exclusively on the power surrounding the installation mechanism of the PEAR installer itself. When you see a reference to PEAR in this book, you should know that it is in fact a reference to the PEAR installer (http://pear.php.net/PEAR) and not to the repository at large.
The PEAR installer consists of four abstract task-oriented sections:
package.xmlparser and dependency processorFile installation processor, configuration processor, and package registry
User front end and command processor
Remote server synchronization and downloading engine
Fortunately, as an end-user, you don't really need to know or care about any of these beyond the way that your application communicates with the installer and how people will actually use the installer to install your code.
First and foremost, you need to understand how PEAR actually installs its packages, as this is a little different from the old unzip-and-go philosophy. PEAR categorizes files into different types, and installs each file type differently. For instance, files of type php will be installed into a subdirectory of the user's configuration variable php_dir. So if the user has set php_dir to /usr/local/lib/php/pear, a file that is packaged in directory Foo/Bar/Test.php will be installed into /usr/local/lib/php/pear/Foo/Bar/Test.php. Files of type data will be installed into a subdirectory of the user's configuration variable data_dir, but unlike PHP files, data files are installed into their own private sub-directory based on the package name. If the user has set data_dir to be /usr/local/lib/php/data and the package is named "TestPackage", a file that is packaged in directory Foo/Bar/Test.dat will not be installed at /usr/local/lib/php/data/Foo/Bar/Test.dat, but instead be installed in /usr/local/lib/php/data/TestPackage/Foo/Bar/Test.dat! This and other details of PEAR's installation are covered in Chapter 2.
Next, you need to know a bit about how PEAR knows which files are in a package, what it needs in order to work (i.e. "This package only works in PHP 4.3.0 and newer, and needs any version of the DB_DataObject package, and only versions 1.2.3 of the Log package, recommending version 1.4.6 be installed"), or its dependencies. This information is also covered in Chapter 2, where we learn about the package.xml file format.
After reading Chapters 2 and 3, you should know enough about PEAR to manage the creation of your own packages for local installation, or to propose a new package to the official pear.php.net repository. Should you wish to distribute your packages for others to use, whether it be free, for private clients, or for sale, you will need to have an understanding of how PEAR channels work. Setting up a channel server is a relatively easy task. At the time of writing this chapter, there was one option available for setting up a channel, but several potential competing options are on the verge of completion. It's an exciting time to be involved in PHP! Setting up your own channel is covered in Chapter 5.
Of course, not everyone is distributing their code publicly. Most developers are busy designing their own websites either by themselves or in a team. The PEAR installer is a highly effective tool for managing a complete website when used in conjunction with a revision control system. Chapter 4 covers this topic in great detail.
In short, the PEAR installer is one of the most effective tools for managing a high-quality software library, high-quality application, or a high-quality website.