PEAR 1.4.0 nears feature completion

It's been a while since I said anything about development on the PEAR installer. I thought people might like to know a bit [unofficially] of what has been going on.

Since the last post, I realized that in order to implement mirroring of channel servers effectively, there would need to be an easy way to retrieve data without demanding a lot from the mirrors. This really means that I needed to implement REST properly, as a REST-based channel server can be mirrored with practically no effort from the mirroring site, and strips a tremendous amount of potential complexity from the parent site. So, I have been chugging away in my spare time to get this feature implemented. So far, the server-side of things is implemented in Chiara_PEAR_Server (as yet unreleased) and at pear.php.net. I've almost completed unit-testing the client side of things, which is a big step towards ensuring the stability of the new feature.

The other nagging problem has been how to specify that PEAR_Frontend_Web 0.4 and earlier won't work with PEAR 1.4.0, and that PEAR_Frontend_Gtk 0.3 won't work with PEAR 1.4.0. The way it is done now is via an optional dependency on the packages. This can cause them to be installed inadvertantly if using the --alldeps installation option. This is not good, as the only thing needed is to prevent installation of incompatible versions of the frontends, or upgrading to PEAR if either of them is installed. The rel="ne" dependency in package.xml 1.0 should work for this purpose, but in package.xml 2.0, there was nothing that would work. A few days ago, I realized that the answer was right under my nose. We already have a <conflicts/> tag that is used to tell the installer that our trusty package conflicts with another package. All that is needed is to add the ability to specify that a dependency conflicts with a particular set of a dependency's releases. In other words, it simply negates the normal purpose of a dependency. Normally, dependencies tell the installer that our trusty package can't function without the dependency, and will install it if the user requests it. The addition of <conflicts/> tells the installer that our trust package can't function with the dependency, and it will never be installed.

The only features that I wish to see avialable prior to a beta release are a working phar-based installation option for PEAR (that's using PHP_Archive, for those who haven't been following my blog), and a working first draft of PEAR_PackageFile2Manager, a package for managing package.xml 2.0. The reason I want to make sure that PEAR_PackageFile2Manager is workable is so that any design changes needed to PEAR_PackageFile_v2_rw in PEAR can be made prior to the feature-freeze mode.

I also think it is very, very important that the documentation for PEAR be complete prior to the first beta. Why I want it to be easy for people to distinguish between mis-use of the package, and a bug. This will also make it easy for folks to test the boundaries of what should be possible. This of course will lead to an ultra-stable release of PEAR 1.4.0, which is crucial to the success of the new features.

The good news is that summer time means some of the dormant PEAR developers will emerge and we can start arguing about the way I've implemented existing features . Hopefully this will lead to better code and not too many delays, as it is looking possible that PEAR 1.4.0 might be ready in time for PHP 5.1. Wouldn't that be grand!