Greg
Beaver writes in his blog about PEAR, the new PEAR channels, and
some issues he sees with PEAR and its developers. Greg is responsible for
the latest version of PEAR and the PEAR installer -- and for the development
of PEAR channels. The particular link referenced above makes reference to a
thread on the PEAR-dev mailing list... that I originated, when asking
whether or not Cgiapp might be a good fit for PEAR.
I've been following with some interest Greg's development of channels, but
for a while couldn't see quite what the point was.... until pearified.net
started offering Smarty via a pear channel. Installing Smarty via the PEAR
installer is incredibly simple -- and points towards a great method of
distribution of PHP code.
Greg is absolutely right in his post -- the best thing about PEAR is the
installer. However, there's some wonderful code in the repository as well. I
couldn't do my job without the likes of Log, DB, Cache_Lite, Pager, and
others; they provide the little pieces that make a large job into a few
lines of code.
However, I've also been observing the pear-dev list for over six months now,
while trying to decide whether or not to propose some of my own code for
inclusion. I feel that the code I have is definitely in the spirit of PEAR
-- good, reusable, extensible, glue code that can be used for a variety of
projects. However, it also falls under an umbrella that appears to be
anathema to many PEAR developers: the framework. And that's how the whole
thread exploded.
I still think Cgiapp would be a good fit for PEAR. However, I am not going
to consider it at this time, for several reasons:
- I don't have the time or energy to argue why I think Cgiapp would fit.
If I thought it would be an easy argument, or that it would simply involve
tweaking Cgiapp slightly, I'd do it in an instant. But from the comments
I've read in response to my query, it sounds like some very core and vocal
members of PEAR simply feel frameworks of any sort are not PEAR's territory,
and I think they would lobby effectively against the proposal.
- I truly feel that Cgiapp should stay as true as possible to its Perl
predecessor. I want the APIs to be the same, and I want it to develop in the
same direction. I suspect that if I were to go through the PEAR proposal
process, I'd have to lose this integrity in order for it to pass muster.
- With the advent of PEAR channels in the upcoming 1.4.0 release, there's
no reason I couldn't set up a PEAR channel of my own on the sourceforge site
-- or join pearified.net. I think Greg hit the nail on the head here:
channels open up possibilities for PHP developers, and particularly for PHP
developers who may not want to or have the time to go through the PEAR
proposal process -- or who are offering packages that fall outside PEAR's
scope. The PEAR installer, coupled with channels, creates an incredible
distribution channel.
I have the utmost respect for PEAR, and I've seen it advance tremendously in
the past year; as mentioned above, I couldn't do my job nearly as well or
effectively without the tools PEAR provides. However, I simply don't see how
Cgiapp could possibly thrive in PEAR at this time. I think Greg's
admonishment to his fellow PEAR devs should definitely be heeded. PEAR needs
to look beyond itself if it wishes to attract new and talented PHP
developers.
