Re: Forking PEAR

Heino H. Gehlsen wrote:

Part of the community is extremely conservative, and that's defiantly the way to go, when stability is an issue, but blindly forcing backward compatibility and too conservative is extremely counter productive, and it's defiantly a problem when only one repository/release exists and a new major language upgrade is breathing down our necks.

I share the opinion that PEAR is too conservative. The reactionary approach to PHP5 has been discouraging. And the general lack of knowledge about PHP5 (which has been in various stages of beta release for over a year) is simply staggering. For being a group intent on setting standards for PHP quality and usage, the official opinions articulated by PEAR are lagging way behind. PEAR tries too hard to be all things to everyone. It is both a loose community and a rigid community; it is both a repository of re-usable low-level components and completely non-re-usable full-blown applications (e.g. PhpDocumentor); PEAR seems to care about novice PHP users and yet is an OO library implementing many non-elementary design patterns; and lastly, PEAR enforces coherence through naming & coding standards, but thusfar ignores much larger coherence issues of package interoperability and design. Of course that's very much a different discussion, but I think the debates are as fervent as they are largely owing to this lack of definition. If PEAR could just decide, for example, that it is a "set of tools for novice PHP developers" then those of us trying to push exception use would take our evangelism elsewhere. :)

I'd like to propose that PEAR should be forked into separate channels each time a new major version of the Zend engine is rolled out. With the upcoming channel feature this should be possible. This way we'd have separate repositories/channels, each embracing new features of the corresponding PHP version, but NOT features of any future major engine versions! Currently we would have two repositories: one PHP4/Zend1-compatible and one PHP5/Zend2-compatible. The former being the current well tested (and partially stable) repository, and the later being a new clean repository. Each channel/repository could even have its own coding standard, so that needed changes could be made without annoying those who prefer staying with the previous stable PHP version.

I think this is a very good idea. As you mention, it is an idea well proven by OS distros.

Personally I believe this is a win-win solution. PEAR started rather ungoverned, and a lot of (sorry to say this) crappy code came into the repository way to easily and the APIs were settled way to fast. In my opinion it's time to start over (using channels instead of wierd package version numbers such as "IPv4_3"), and now that PHP have gotten features like interfaces etc., I think it's about time to reinvent the wheel.

Absolutely. I think that interfaces have the potential to really change what PEAR is. The loosely coupled components that would be made possible by a collection of interfaces would make for a much greater degree of code reuse accross the PHP community -- not just within PEAR.

A more controversial proposal would be that PEAR should be further forked. The installer should be totally separated from the current repository; it should be considered a part of PHP. No, I'm not on a major crusade here, since the proposal wouldn't affect the way anything is installed. Actually I 'm only proposing that the PEAR installer should be moved into a separate channel/repository (or rather that non Installer packages should be moved into a different channel/repository), and that the installer should be allowed to rely on 'external' packages (e.g. from the current repository/channel).

I think it would be good to remove the installer. Make it just as easy to install external/non-PEAR packages as it is to install PEAR packages. It sounds, generally, like the idea of a PHP5/PHP4 channel is yet another dimension to the channels that are currently in development/testing for the PEAR installer. I think that apt is a good model for the final design, where anyone can add their own sources and those sources can provide stable/testing/devel channels. Perhaps that is exactly how it's designed. Mostly, why *haven't* channels been implemented yet? Is it a matter of needing more developers to contribute time? Is there a technical limitation? It seems PEAR needs a solution now because PHP5 is stable & PEAR is just going to become a mess of PHP4/PHP5 packages (e.g. what happens when someone backports Net_GeoIP to PHP4?....Net_GeoIP0? Net_GeoIP2?). Hans