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:
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
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
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.
