New PEARs for the community - Blog - Open Source - - php, photography and private stuff

New PEARs for the community

On September 20th Greg Beaver (for a longer time now the main man behind the PEAR Installer) announced the stable release of the new PEAR Installer Version 1.4.0. Yesterday Gerg updated the release to an even more advanced version 1.4.1 which solves some minor bugs and adds some cool features for PECL developers. I think now it's time to write some introductional words about the new feature release of our Installer, which will steer the project into a completly new direction, since it's now possible for everybody to set up his own PEAR channel server and to distribute his applications comfortably through the PEAR Installer.

I recommend to everyone out there to upgrade his/her PEAR installation to take advantage of the huge improvements, like:

  • Channel support.

  • Completly revised dependency handling.

  • Much more secure and performant REST web service backend.

  • Drastically enhanced PECL support.

  • Post install scripts.

  • ...

For a full list and some introductory words, please refer to the extended entry.

To upgrade your PEAR installation simply do $ pear upgrade PEAR. A $ pear channel-update pear is recommended afterwards. The new Installer version maintains BC to the old version, so you don't loose anything by upgrading, but gain

For more info on what is new in PEAR 1.4 you should take a look at the extended version of this entry. So far, I'm very sure that our new version will be a milestone for installing and distributing PHP based source code (and maybe even other languages?) and that, with it's new exciting features and the fixed oddities of the old versions, it will become _the_ standard for application distribution in the PHP world.

Special thanks from my side to Greg, who did a really amazing job and worked like a horse to get everything done, and (self-evident) to anybody out there who helped with this. PEAR the wold! ;)

P.S.: And don't forget to register your own channel server on - The PEAR channel portal! :)

PEAR 1.4 is a huge milestone in the development of the PEAR Installer. It is basically a rewrite of the older version, enhanced by many exciting features and fixing almost any oddity. Although the release cycle has been drastically shortened (from beta to stable) by the need of a new stable version for PHP 5.1 (among other issues), the new version seems to be rock solid (after a first update), which is mostly caused by Greg's phantastic test suite (about 650 tests) and the help of many PEAR developers and users by testing the alpha and beta versions.

Update: Thanks to Greg for some corrections.

In following I'll try to provide a complete list of what has changed from 1.3.x to 1.4.1:

  • Channels

    • A channel is a server application that provides PEAR conform packages and can be used like the PEAR channel itself. Everyone can set up his own channel and provide his own applications through it. Users can then install and maintain the provided packages simply by using the PEAR installer. The new commands $ pear channel-``*``* have been invented to allow users to add new channels to their PEAR installation (using *$ pear channel-discover

    • The new PEAR channels provide a different webservices interface than PEAR 1.3 utilized: REST. REST is a very simple and lighweight web service protocoll, that improves the speed of our Installer and makes it more secure than the former XML-RPC implementation was. PEAR 1.4 is able to utilize both web services, the old XML-RPC and the new REST, although the PEAR channel itself offers REST be now, too. The REST information provided by the channels is also aggregated on the PEAR channel portal

    • The new $ pecl command allows you to install packages from our partner project PECL without entering $ pear install pecl/MyPackage (because PECL now is a more or less independant channel) and offers some nice features for the installation (users) and packaging (developers) of PHP extensions (which is the purpose of PECL). A very good example for the usage of these features is the complex PHP extension PHP Data Objects (PDO).

  • Dependencies

    • The handling of dependencies has been widely improved with the new version. The definition of dependencies has been changed to a much more flexible way with the new package definition format package2.xml.

    • Dependencies are now resolved automatically by the Installer, if you want it: The switch "-a" makes the Installer grab all packages that are utilized by the one, you requested to install, from the web and install them first. The "-o" switch does the same, but loads only required packages and leaves optional dependencies out.

    • Dependencies are now checked before the package is actually downloaded (1.3 checked dependencies on the client side only) from the channel server, which reduces traffic, time and annoyance.

    • Also gained by the new package2.xml format is the possibillity to define dependency groups. This is extremly useful, if your package can provide more advanced features, which depend on other packages, but does not necessarily require them to be there to work in general. It e.g. allows users to do $ pear install pear#webinstaller to install the web frontend feature of the PEAR installer.

    • During uninstallation of a package the dependencies are now checked much more carefully, to reduce the risc of fragging a PEAR installation. Beside that, the new package2.xml allows to define that your package works definitly with a specific version of another package, but that it's not ensured to work with newer versions. This will also reduce the possibility of running into unexpected BC break problems.

    • The much more flexible definition of dependencies now allows PECL packages to be packaged and installed much more convenient.

    • Dependencies can not only point to packages provided through the PEAR channel itself or packages that simply lie on a webserver (using their URL), but also to any other package from any other channel (so called "cross channel depenencies"). Packages that get installed manually (not from a channel, but either locally or from a URL) are now checked for dependencies correctly, too.

  • Remote installation & mirroring

    • A major issue in the past was the possibility to install PEAR onto a shared hosting environment (what lot's of potential PEAR users propably want to / must do). All ways to achieve a private PEAR installation on a shared host (without shell access) required hard work and contained nasty pitfalls. The new PEAR_RemoteInstaller package enhances the PEAR installer to be able to install packages to a remote machine, using an FTP account.

    • If you want to maintain more than 2-3 servers with PEAR in your own network it can be a very good idea to mirror the PEAR repository (or any other channel) locally. This saves you much traffic and setup time, if your servers than access your local PEAR mirror.

  • Packaging

    • Another sweet new feature is the possibillity to package multiple packages into a single one. This basically means, that you can create a package which contains multiple other sub-packages, which get installed all together (or at least some together, as you like). A nice way to bundle e.g. PEAR packages (meaning library packages) together with your application. Each package can be upgraded on it's own (if you like) or just with your bundles (using the new dependency features).

  • File roles & post install scripts

    • The file role scheme of PEAR 1.3 has been revised and now allows you to create custom roles for your files. File roles allow you to determine in general, what will happen with a specific category of files during the installation process (e.g. where to put the files, etc.).

    • Post install scripts are another new invention of 1.4. In 1.3 you could make the Installer perform simple tasks after installing your files (like replacing strings with environment dependent values). With our new version you can a) use the much more advanced integrated "tasks" (e.g. for doing the mentioned replacements) or even create tasks on your own, which can do anything that's possible with PHP (like copying files to directories outside the local PEAR dir, editing config files or initializing a database).

    • The API for own post installation tasks is really simple and offers a very nice interface to interact with the user during the installation process (which was not even possible in former times), like asking for installation pathes or configuration settings.

    • Post install scripts are not executed automatically, but require an explicit call to $ pear run-scripts MyPackage, for security reasons. I assume you don't want to have a package from a 3rd party channel perform a $ rm -rf / on your machine, or? If tasks exist that should be performed the Installer will inform about the scripts and how to run them.

  • package2.xml

    • As mentioned several times, the new Installer version brings a new package.xml version (the files are named package2.xml). This new format is a reworked version of the old one, providing some great new features and fixing a lot of oddities (as one should already have noticed).

    • Packages which are packaged with PEAR 1.4 can contain both versions in paralell, what makes the new packages backwards compatile (BC) to older Installer versions, without loosing features if the new version is available.

    • To make the migration of packages smoother, the command $ pear convert has been introduced, which does a basic conversion form package.xml version 1.0 to 2.0. Because of the more complex features (like the new dependency model) some handwork is required to finish the migration.

    • A better way to maintain both versions in paralell is the usage of PEAR_PackageFileManager which generates both versions from 1 PHP source file and is very comfortable to use (package2.xml integrated since version 1.6.0).

  • PECL

    • The brother project of PEAR, PECL, provides PHP extensions which are not delivered with PHP directly (mostly new extensions before they are added or uncommon ones, which have been moved here). In the old Installer version PECL packages were only supported very limited, what has been drastically improved by the following.

    • The new $ pecl command has been invented, which is almost a link to the $ pear command, but has as it's defualt channel. Aside of that it has enhanced support for installing libraries into PHP by running without the php.ini.

    • As a special sugar the command $pear pickle was invented, which tries to downgrade a package2.xml to a package.xml. This shortcut is very limited, due to the fact that the conversion of package2.xml to package.xml is an extremly complex process and the command works very restrictive.

  • Misc

    • Beside the new commands mentioned during your way down here some more were added which shall be listed here. Additionally, there are some smaller, but neat enhancements, which do not fit into one of the categories above.

    • New commands for $ pear list-files lists all files that are in a package.

    • The equivalent for $pear list-all and $ pear upgrade-all for channels is $ pear update-channels.

    • The $ pear list-all and $ pear remote-list commands have status bars now (very convenient, since these may take extremly long with the number of PEAR packages).

    • Setting the new configuration setting "auto-discover" to 1 saves you from discovering every channel. You'll then have to use the long syntax $ pear install instead of the shortcut $ pear install example/MyPackage which is introduced by the $ pear channel-discover.

Please correct me if I made a mistake or missed something out! I'm pretty sure that this will be a great shot for the PEAR project.

If you liked this blog post or learned something, please consider using flattr to contribute back: .



Add new comment

Fields with bold names are mandatory.