This is a work in progress, and contains ONLY the views of the author
Due to the numorous the-sky-is-falling posts which have appeared on various mailing lists and a couple of blog entries in the last few weeks, I decided to put some time towards documenting the history of PEAR, what it is, where it came from and most importantly where it is going.
I have been working with PHP for 6 years, most of that time I have been using PEAR. I during 2004 and 2005 I wrote over 50 articles which made up the PHPBarnstormer column for phpmag.net. The PHPBarnstormer followed PEAR development and included many tutorials on various packages. I’ve represented PEAR at LinuxTag and two LinuxWorld expos, and have written about PEAR for PHPSolutions and the International PHP Magazine. Most recently I contributed to an upcoming PEAR book by Packt Publishing.
Before taking on the question of where PEAR is going, we have to discuss exactly what PEAR is. PEAR can be broken down into several distict processes
The PEAR installer has always been an integral part of PEAR. Initially it was a simple delivery system which enabled every PHP installation to be able to access the packages which were available through the PEAR code library. The ability to give your project this visibility and ease-of-installation made contributing code to the PEAR project a very attractive option.
The PEAR community consists of both developers who have contributed packages to the PEAR code library, and the users of the packages. The development process is centered around the PEAR Developers mailing list and the PEPr (PEAR Proposal) system. To include your code into PEAR code library, a developer would need to create a proposal, and then would take the package through each step of the proposal system until it was voted upon by a majority of the PEAR developers. The PEAR development process also offers CVS accounts for package maintainers who wish to use it, as well as a bug tracking system, and a documentation hosting system.
The Code Library is the most visible part of PEAR, and currently consists of over 300 independant PHP packages in 40 categories. All code is released under various BSD style Open Source licenses. The packages available range from packages which provide unique functionality to PHP like (Spreadsheet_Excel_Writer), to very widely used packages, such as (ie. DB, Log), and a variety of esoteric packages (Text_figlet, Games_Chess). Just as the functionality of the packages very, so does the stability of the individual packages.
The Myth of PEAR_Error.
One common misconception of PEAR is that all the classes in the PEAR Code library extend the top level Pear class. In the early versions of PEAR it was common to extend the top level PEAR class and inherit the error reporting methods from the parent class. Due to some issues with the the deconstruction methods built into the Pear class, this caused slow-downs in classes which extended.
Changes have been made to the top level PEAR class to be more efficient, but most developers call the PEAR_Error methods statically when using them in their packages, this reduces the overhead of the package significantly. There are other packages such as the validate package, which do not use the PEAR class at all.
While most of packages have a fairly low bug count, not all the packages are formally marked as Stable, more reasons for this later.
The Coding standard was decided on early in PEAR’s history. This is simply a standard to ensure easy readabilty by any developers who work on the individual packages. The coding standard also makes sure that the packages contain the nessesary comment blocks to ensure a minimal level of docbook documentation.
The Quality Assurance process exists as both RFCs which have been accepted through the PEPr process, and the QA team. PEAR’s QA standards ensure that once a package is marked as ‘stable’ backwards compatibility is maintained for the life of that package. The QA team is responsible for monitoring packages which are released and have the ability to remove releases which do not comply to the PEAR quality assurance.
This is by no means a comprehensive explaination of what PEAR is. There are many important aspects that I haven’t touched on, but I think the above information is sufficient a background so we can move on to determine whether or not the sky is falling.
Over the 7 years of it’s existance PEAR has seen changes both in both it’s focus as well as the maintainers and community. In the recent history the development that changed the PATH of PEAR was the development PEAR 1.4 with channel support. The benefit of channel support in PEAR is that it allows developers to use PEAR to deploy their applications without having to be part of the PEAR project or submit their packages to PEAR’s strict coding standard or the QA process.
“Seagull takes advantage of not only many PEAR packages, but of almost all the advanced features of the PEAR installer, including advanced dependency resolution, cross-platform/channel installs, and sub-package management.” Demian Turner - Seagul Project Manager
The channel support in PEAR 1.4 was developed almost single-handedly by Greg Beaver. With PEAR 1.4 came the PEAR channel server, which enables anyone to maintain their own PEAR repository. While PEAR channels are not much talked about they have changed how people use PEAR, and have greatly enlarged the userbase and popluarity of PEAR as a project deployment mechanis.
For an idea of the reach of the PEAR as a deployment mechanism
This is just a sampling of the projects who are using the PEAR installer to deploy their packages. Within this handful of applications we have hundreds of thousands of lines of code which are being deployed using PEAR.
Horde is a PHP application framework, and the application suite that is built on top of it. The most popular Horde application is the IMP webmail client, as well as the suite of groupware applications which are closely integrated through the Horde Framework.
Horde pre-dates PEAR, and has had a close relationship with PEAR since the beginning of PEAR. Horde team members maintain PEAR packages such as Text_CVS and File_PDF, the initial PEAR Coding Standards document was derived from Horde.
The ezcomponents are a relatively newcomer to the PHP package scene, but have quickly gained traction with their stable 1.1 release. The ezcomponents are based on PHP5.1 and provide over 20 packages which can be used as basic building blocks for PHP5 based applications.
While the PEAR code library is similar to the ezcomponents in concept, there are several primary differences. The ezcomponents are developed by eZsystems, and will provide the base libraries for the next generation of eZpublish, their flagship CMS product. Because of this, the development team is focused on creating a set of re-usable components. Focus is also put on design, documentation and good usage of PHP5 technologies. For enterprise projects eZpublish also offer clear IP rights and paid support.
PHP Application Tools has run in parallel to PEAR for many years, with Stephan Schmidt contributing heavily to both projects. PAT offers an error handling system which is similar to PEAR and many other useful packages. One of the PAT highlights is patForms, which provides form building mechanism. PatForms is used in projects such as the bitflux CMS.
Solar PHP is the brainchild of Paul M. Jones, a long time contributer and maintainer of PEAR packages. The goals of Solar PHP are similar to PEAR, the main difference is Solar PHP‘s focus on PHP5 as well as the YAWP framework. A highlight of Solar PHP is the Savant template system which uses PHP as the template language and provides a lightweight templating solution.
Pearified pearifies non-PEAR software packages, enabling easy installation by anyone with a PHP installation. Using Pearified, you can quickly install or upgrade your smarty installation. Pearified also distributes javascript libraries, icon packages, wysiwyg text editors, and is quickly growing. Pearified is spearheaded by Clay Loveless.
Pearified developed the
Gnope is a repository for reusable packages and applications which are built around the PHP-GTK2 library. Gnope includes over 20 packages which include libraries, applications and games. Gnope also created the PHP-GTK2 based PEAR package installer, this can be used on any operating system to manage your PEAR package repository.
Apart from the package repository Gnope also focuses on the development of PHP-GTK2 applications and includes simple tutorials on how to start developing and distributing your PHP-GTK2 application.
The Seagull project is a mature OOP framework and CMS. The Seagull framework makes extensive use of the PEAR libraries and includes a PEAR package management module which allows users to manage their local PEAR repository from within the CMS.
Propel is an object persistance platform for PHP. Other than the fact that Propel, and the underlying Database abstraction layer are offered via the propel pear channel server, there are very few connections between PEAR and Propel.
One interesting tie-in is the fact that the patForms packaged from PHP Application Tools includes a driver for propel. This allows patForms to automatically generate forms based on the ORM model that propel provides. Using the PEAR package system it could be possible to create a dependancy from patForms to the propel package through a cross-server dependancy. This means that it is entirely possible that when packaging patForms the authors can require the users to install propel first, or automatically install propel if the correct flags are set on the client pear installation.
The second major advancement that we’ve seen in the last year, is the creation of the .phar php archives.
Phar was the creation of Davey Shafik, and initially was a cool hack which embedded PHP code into a legitimate tar archive. This enabled multiple files to be grouped together into an archive, then accessed transparantly through a PHP stream wrapper.
Greg Beaver took the work that Davey had done and with the help of Marcus Börger extended it, and used it to bundle the PEAR installer for inclusion in the PHP releases.
Since it’s initial development, the functions for the creation and management of .phar files have been wrapped into the PEAR class PHP_Archive which is being actively developed, making PHP_Archives another excellent way to deploy PHP code.
(talk about packages under development, existing packages, stability levels, pear isn’t dieing, etc)
PEAR was started in 1999 by Stig Bakken, who laid the foundation and brought the community together. Because of changes in personal focus, once PEAR was well established Stig withdrew from active development. Over the years the developers which made up the PEAR community gradually changed. Founding members such as Thomas Cox moved on to other developer work, active developers who maintained many packages such as Stefan Schmidt (who wrote/maintained many of the XML_* packages) changed his focus away from PEAR (although he still maintains packages in the php-tools project). As is the typical cycle of Open Source development, many other developers, and community members contributed a various amounts of code/time into the PEAR project and then when they found that they could no longer maintain their active involvement removed themselves and new developers filled the gap.
There are several reasons why developers choose to leave the PEAR project. The main reason is that developers find themselves with less time on their hands than they did when they started with the project.
In other cases, the developer decides that the PEAR framework no longer suits their development needs and they move the package development elsewhere. Because of the fact that it’s so easy to set up your own channel server, the developer can still offer their packages as PEAR packages and even maintain dependancies with PEAR packages through cross-channel dependancies.
Like all Open Source projects, the development of some packages often slows or stops due to the workload of the package maintainer. This means that occasionally package development will slow down, or packages will simply be abandoned by the maintainer.
PEAR packages usually have several PEAR community members who contribute to each package. In most cases the lead developer is the original author of the PEAR package, they are the only person who is able to create releases of the package. There are usually more developers who are contributers, helpers or documentation writers.
Generally when a PEAR package maintainer decides to step away from the development of their package they will send an email to the PEAR Development mailing list and request volunteers to maintain their packages. In many cases one of the developers who is already working on the package will take on the roll of lead developer, in other cases another community member will take over from the Lead developer in that roll. Often the original lead developer will continue to work on the package, just in a lesser capacity making the roll-over smooth.
In cases where a package is abandoned without another developer taking over the roll as lead developer, it becomes the responsibilty of the Quality Assurance team to ensure that any critical bugs which arise in the package are fixed, and a release is made.
There are a lot of packages that have not had a release in the last year, they are not maintained, but also fairly bug free and usable (or sometimes with numerous unfixed bugs but still popular as in the unique case of Spreadsheet_Excel_Writer).
There have been talk about creating a “PEAR Graveyard” where unmaintained pakages will go, but these plans have never solidified.
The PEAR community continues to grow, both horizontally in the number of community members, but also horizontally in the number of projects which use PEAR packages and the PEAR package deployment system. At the same time PHP continues to grow, and in the recent versions of PHP we have seen many additions to PHP which can be seen as replacements for current PEAR componants. This is most obvious in the XML section, which provided unique functionality to PHP4 but in PHP5 similar functionality can be obtained through the use of SimpleXML and/or XMLReader/XMLWriter. The Validate package provides many valuable filtering and validation routines, however the new filter PHP extension would be a better choice as it provides similar functionality but is a PHP extension an therefore a faster and more robust solution.
The issues involved with managing a growing community as well as dealing with he continual evolution presents unique challenges which the PEAR community have to deal with.
Because of PEAR’s responsibliy to creating stable platforms and not breakign backwards compatibility in their stable packages, much of the development has been restricted to the PHP4 platform, however steps are being taken to move the primary development focus to PHP5.
In the late stages of PHP5’s lengthy beta phase, the PEAR development team put a lot of effort into ensuring that the PHP4 packages ran under PHP5 (without E_STRICT turned on). As of July 2006, the PEAR community voted that all new packages run error free under E_STRICT PHP5.
These are just a few of the many issues that face a project as old and large as PEAR. As a long time user of PEAR and a community member, I have no doubt that the PEAR community will continue to grow with the techonlogy and user group that it supports and will continue to be a major player in the roll of PHP as a web development platform for years to come.
