Thank You Graham Barr

brian_d_foy on 2007-08-23T19:13:00

For many people, search.cpan.org is CPAN. It is very easy to take it for granted. It's always there and it just works. It allows us to find modules, read their documentation, track version histories and even just plain read the source - with ease. Through links to other sites in the perl.org stable, it also allows us to easily check test results for a distribution, report and review bugs and patches, share ratings and reviews, annotate the documentation and all the other things I've forgotten.

I was reminded of the awesome coolness of search.cpan.org as I was wading through RubyForge for a project I'm currently working on. The contrast was stark. And it's not that RubyForge is terrible, in fact it does a reasonable job. But it's not awesomely cool.

Thanks Graham and everyone else involved


Apples to Oranges

djberg96 on 2007-08-23T13:01:16

"I was reminded of the awesome coolness of search.cpan.org as I was wading through RubyForge for a project I'm currently working on. The contrast was stark. And it's not that RubyForge is terrible, in fact it does a reasonable job. But it's not awesomely cool."

To paraphrase samtregar, RubyForge is a collaborative development environment, CPAN is a search engine (with extra goodies). A closer analogue would be the RAA, which does suck compared to CPAN. Someday I'm going to rewrite that puppy. The RAA I mean. :)

Not that RubyForge couldn't use a makeover. I think we should rewrite it using redMine personally.

Anyway, I brought up the possibility of a PerlForge a long time ago, but it didn't receive a warm response.

Re:Apples to Oranges

djberg96 on 2007-08-23T20:25:43

s/CPAN/search.cpan.org

PerlForge

slanning on 2007-08-23T14:40:14

Anyway, I brought up the possibility of a PerlForge [perl.org] a long time ago, but it didn't receive a warm response.

I like the idea. There are some times when I make a Perl application, but it's not really something like a library that other people could use, so I just don't put it on CPAN. And somehow putting it on Sourceforge seems like overkill or somehow not appropriate.

Re:PerlForge

grantm on 2007-08-23T22:30:39

«There are some times when I make a Perl application, but it's not really something like a library that other people could use, so I just don't put it on CPAN.»

I used to think that too but have changed my mind. The App:: hierarchy in CPAN is a good place for this sort of thing. I find my application is generally a short wrapper script and the real logic is in one or more modules. They're not necessarily generic reusable libraries but organising things that way is great for regression testing.

The simple genius of CPAN to some degree is the standardised tarball layout - so many things flow from that. If you package your app in the standard way and upload it to CPAN then people can use a standard mechanism to install it. There are also tools for auto generating packages for Linux distros from CPAN tarballs.

«And somehow putting it on Sourceforge seems like overkill or somehow not appropriate.»

That is kind of a different issue. CPAN is not in the business of providing subversion (or similar) hosting and it would be difficult to justify the effort required to do that when SourceForge and GoogleCode already exist. Of course if one is using git then the overheads for having a publically readable repo are lower.

Source availability?

jrockway on 2007-08-24T02:12:19

Speaking of search.cpan :)

I've wanted to add some features to search.cpan for a while (proper Unicode support, proper location of .pod files with shadowing .pm files), but I can't find the source anywhere. Can someone point me in the right direction?

Re:Source availability?

Alias on 2007-08-24T03:17:01

The source for search.cpan.org is closed, Graham wrote it.

Re:Source availability?

jrockway on 2007-08-24T17:41:41

My questions was a nice way of asking, "why is it closed source?".