On 29 November 1999, T-Methy Moddletin said:
> >Oh well, that's the mess the Perl world was in five years ago before
> >Jarkko Hietaniemi came along and cooked up CPAN.
> Hmmm, i'm not familiar with pre-CPAN Perl. Perhaps you could enlighten
> me? What exactly was the nature of the "mess"? Perhaps there are other
> ways than CPAN to address some of the problems? Non standard packages?
> (You're taking care of that problem, i hope!) But perhaps non-standard
> naming as well. Hideously ugly, eyeball splitting web page colours and
> designs? (even more eyeball splitting than perl code itself?! <G>).
> Broken links?
Back in ... ummm... 1995-6 or so, there were a bunch of big, well-known
Perl ftp archives. But none of them had everything, none of them were
particularly well-organized, and the damn things kept flitting in and
out of existence (or so it seemed to me when I was trying desperately to
track down a tarball for Perl 5.001m, rather than the 5.001 tarball and
patches a .. m).
The story I heard (from Tim Bunce and Jarkko Hietaniemi at the O'Reilly
Open Source Conference back in August) is something like this: the
perl-packrats mailing list had existed for some time as a forum for
archive site maintainers and users to bitch, whine, gripe, collude, etc.
It didn't accomplish much until Jarkko arrogantly and unilaterally
created the "Comprehensive Perl Archive Network" on a machine in
Helsinki. It caught on pretty quick. Now, there are roughly 100 CPAN
mirrors around the world, and I can find whatever I want as fast as I
And if you want a meta-archive, there's search.cpan.org, which IMHO is
what the Python world really needs. I don't care what you think about
Perl, go visit that site *now*. From the top, you can browse by module
category (taken straight from the Perl Module List). Or you can search
by author name (or ID -- every CPAN contributor has a user ID), module
name, or distribution name. You can search the text of all the
documentation for every module uploaded to CPAN.
This is an absolutely red-hot, kick-ass web site. Poking around it, I'm
trying to remember why I use Python. Oh yeah, it has actual syntactic
support for OO programming, that's why. ;-)
I think one of the things I like about search.cpan.org is that it's
sort-of a meta-archive, and sort of a centralized archive. All the
search results you get back include the author's home page and email
address, but if you want to download something -- bam, it comes straight
from the archive at perl.com. (I guess it has more bandwidth than
cpan.org or something.)
The biggest problem I have with meta-archives is the one you have
already found: broken links. And you already know the two most obvious
solutions: scan the database regularly and rigorously, bitching at
developers whose links break; and have an optional central archive that
downloads stuff from developer's pages and puts it somewhere whose links
I haven't used freshmeat much, but I've been impressed -- I don't think
I've seen many broken links. Compare that to my unpleasant experience
trying to find some free Java classes (because Sun somehow forgot that
"the programming language for the Internet" might need to do MIME
decoding -- oops). There is a big meta-archive at gamelan.com, but
for everything I found -- bam, broken links everywhere.
I think this just means that Linux developers have more of a clue about
Internet culture than Java developers. I would expect the same degree
of cluefulness from Python programmers, so I don't think a Python
meta-archive would be as bad as gamelan.com... but it still needs
> Of course if there was a central archive, that takes care of finding
> things as well (assuming everyone wants to bother with going to the
> trouble of getting archived there). Still I must dissent. In
> retrospect, I am not fond of CPAN. I do not miss it. I do not consider
> it a model for emulation. It had perhaps some useful attributes----but
> I am (and hopefully I don't just say this because it is the nature of
> my-project-which-i-must-protect) genuinely in favour of
> decentralised resources. I think it's more encouraging to people to
> directly and easily control and release their stuff (and for those
> who want to upload somewhere there is still ftp.python.org!) While
> there are certain weaknesses and logistic complications (and yeah,
> perhaps "mess" also!) it seems a much freer environment to me. Less
> stuffy, as it were. Less official! Perhaps my biases are showing a
> little too strongly. I find the rigidity of CPAN just a little too
> intimidating, in fact.
Legitimate difference of opinion. I think the B&D of CPAN (and all the
other tools and tricks involved, principally MakeMaker and POD) is well
worth it considering the payoff. Part of the payoff is search.cpan.org,
and part is the ability to install a large and complex module
distribution with a single command (at least under Unix):
perl -MCPAN -e 'install ("Tk");'
... or something like that. If you have a functioning Perl
installation, you might try that out. If things work out right, it does
*everything* needed to find, download, configure, build, test, and
install that very large module distribution. The only thing it doesn't
do is order *Learning Perl/Tk* from amazon.com for you.
I will continue to argue for just the right amount of bondage,
discipline, structure, and bureaucracy to achieve that level of
automation. The trick is using the *bare minimum* of bureaucracy that
will achieve the desired result, and that's why I will continue to
listen to people like you and Greg Stein arguing for anarchy. ;-)
> I have never used as CSV in my live-long life. And it probably shows.
> (-: I see all the strange $ codes in people's source and i think: wow,
> that looks impressively obscure and archane, someday i'll have to
> figure that out! However, i'm open to all these ideas. I have nothing
> intrinsically against a central archive, and would certainly welcome
> it (and happily index it---for myself, if no one else) --- let me
> know when you open one. (-:
I think you mean CVS. I strongly recommend the RCS/SCCS book from
O'Reilly. (Just ignore the SCCS chapters.) If you're a lone
programmer, CVS is overkill and RCS usually does the trick. For group
projects, CVS (or something like it) is absolutely critical. Again,
it's a question of imposing just enough bureaucracy and structure to get
things done efficiently without bogging everyone down. RCS and CVS
provide the right level of bureaucracy for me; other projects might
prefer something like Aegis (which, roughly, requires that you write
test code to validate every change you want to check in -- ouch!).
Greg Ward - software developer gward(a)cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913