PEAR is dedicated to Malin Bakken, born 1999-11-21.
PEAR is short for "PHP Extension and Application Repository" and is pronounced just like the fruit. The purpose of PEAR is to provide:
A structured library of open-sourced code for PHP users
A system for code distribution and package maintenance
A standard style for code written in PHP, specified here
The PHP Foundation Classes (PFC), see more below
The PHP Extension Community Library (PECL), see more below
A web site, mailing lists and download mirrors to support the PHP/PEAR community
PEAR is a community-driven project with the PEAR Group as the governing body. The project has been founded by Stig S. Bakken in 1999 and quite a lot of people have joined the project since then.
The code in PEAR is partitioned in "packages". Each package is a separate project with its own development team, version number, release cycle, documentation and a defined relation to other packages (including dependencies). Packages are distributed as gzipped tar files with a description file inside, and installed on your local system using the PEAR installer.
There are two types of packages: source packages (containing source files only), and binary packages (containing platform-specific binary files, and possible source files). Installing source packages with C code obviously requires a C build environment.
PEAR defines a package tree, where each "node" in the tree is represented by a part of the package name. The nodes are organized by simple descriptive topics, and each part is separated by an underscore. Examples of package names are "MP3_Id", "Archive_Tar" and "HTTP_Post".
Packages may relate to eachother through explicit dependencies, but there is no automatic relation between for example a package and its "parent" in the package tree (for example, "HTTP_Post" is by default independent of "HTTP").
A few top-level nodes in the package tree called "sub-repositories" have special functions, currently these are PECL, Gtk and App. For each of these, different rules apply, see more in the description of each sub-repository below.
A style guide, the PEAR Coding Standards (short PCS), exists to ease collaboration between PEAR developers, to help quality and portability, and to help PEAR contributors to provide consistent-looking-and-feeling APIs. For packages in the PFC, this standard applies strictly, for non-PFC packages it applies more relaxed.
All PEAR packages are registered in and uploaded to a central database available at pear.php.net. Open-sourced third-party packages may also be registered and uploaded. Closed-source packages may be installed by the PEAR installer, but the PEAR database is for open-source code only.
Pear.php.net will provide both a human-friendly (HTML) and machine-friendly (currently XML-RPC) interface to the PEAR database. Package downloads are done with plain HTTP. Other functions the pear.php.net site will provide are:
user account management (integrated with the CVS server)
package management
release management
Packages are distributed as a gzipped tar file with an XML description file inside. The description file contains some information about the package, a list of files and their roles, and dependencies.
The PHP Foundation Classes is a subset of PEAR that focuses on quality, generality, interoperability and compatibility. If PHP is going to continue bundling PEAR packages beyond the installer, it will bundle the PFC.
Focus on quality means that no packages or releases with less than "stable" quality are accepted in the PFC.
Generality means that packages should not be more than reasonably specific to any type of environment (such as an output format like HTML, an operating system, a web server or SAPI backend etc).
Interoperable packages work well with other packages, have stable, standardized APIs, prefer other well-established (and also interoperable) components and also work well in different environments (PHP version, SAPI backend, operating system etc.)
Compatibility is not just about supporting the same syntax and semantics as earlier versions, it is also about planning ahead when writing the code. Designing code so it would be easy, or at least possible, to add features that are likely to appear later, gives code that is also "forward-compatible".
PECL (pronounced "pickle") used to be a sub-repository of PEAR for C extensions ala those distributed with PHP 4, in fact, having somewhere to move extensions to from PHP was one of the motivations when creating PECL. Extensions in PECL follow PHP's coding standards rather than PEAR's, but they are distributed and installed as PEAR packages.
The process of moving an extension from PHP to PECL is referred to as "pickling".
In October 2003 PECL has become an independent project, which does not belong to PEAR anymore. (Except for the infrastructure, which PECL borrows from PEAR.) More information and all PECL packages can now be found on the PECL homepage. During the PECL spin-off, the project has also been renamed from "PHP Extension Code Library" to "PHP Extension Community Library".
Gtk packages are packages that provide software which uses the technology of the PHP-GTK project. Code in this sub-repository follows PEAR's coding standards.
Right now there is no definitive plan on how they will be released in PEAR.
TBD