James

i only use https://metacpan.org/ these days, i even have a it in my hosts file so if i click a link to search.cpan.org then it takes me to metacpan

46.43.35.68 search.cpan.org

use metacpan.org

Whilst you can just use metacpan, it's a bit of a sad state of affairs :(

Last year I wrote about some ways to make it easier to use MetaCPAN.

MetaCPAN has a lot of advantages, but there is one thing about search.cpan.org which I will miss: the fact that development releases were (so to speak) first-class objects. The author's page showed the latest release regardless of whether it was a development or production release.

MetaCPAN is (according to its FAQ) driven by the module index, which does not include development releases. This means the author's page shows only production releases. You can find a development release if you dig, and if there has been at least one production release of the module. Otherwise you are out of luck.

Oh, well, I suppose I will just have to be less lazy (or more intelligently lazy) about figuring out when I put out a development release and neglected to follow it up with a production release.

I've seen this happen a few times, and I still get the same feeling that the metacpan fans are out to kill search.cpan.org. Can't the two engines live peacefully in parallel? Or maybe it's the "King of the Hill" syndrome?

Speaking of search engines for CPAN, there's one that seem to have disappeared without much fanfare: http://kobesearch.cpan.org/ (aka http://cpan.uwinnipeg.ca/). This makes me sad. If I remember correctly, it also had features that search.cpan.org lacked, like links to PPM repositories. And it was open source (which is the main issue most people seemed to have with s.c.o.).

Now the good news is that is has a maintainer and some relatively recent releases. Now the real question is: is there a public web site running CPAN-Search-Lite?

The CPAN search world surely needs diversity as much as CPAN itself.

To respond to the issue about why metacpan fans sometimes seem to disparage search.cpan.org:

Although I know one mantra of Perl is 'there is more than one way..' and that in an ideal world the more the merrier, and let the best XXX win, etc. but the issue here is that those of us working on trying to improve Perl visibly beyond the community echo chamber, having two sites splits the SEO traffic and as a result tends to dilute the overall Perl rating. It would be ideal if one site got all the traffic because in this world people look at site traffic as a meter of health. Having two sites hurts us in this because it makes Perl at first glance look less popular than it really is. This is just the way google and search engines work.

If you can show me that I am wrong in thinking this, I will gladly back off and apologize :)

jnap

I like search.cpan.org because it's much faster than metacpan.org. Also some modules don't show up on metacpan.org, and it's often necessary to do "shift-reload" on metacpan.org to re-synch the pages.

I think we're in danger of being insular here.

People inside the echo chamber know about Metacpan and either use it in preference to search.cpan.org or switch to it if, as is often the case at the moment, search.cpan.org is down.

People outside the echo chamber are less aware of Metacpan. If search.cpan.org is down, they just take it as more evidence that Perl is d**ng.

A few reasons why I'm a MetaCPAN promoter:

• search.cpan.org still has the look of 1997 web sites. Just this can let people think that Perl is stuck there.
• you can submit issues about MetaCPAN, they are public, and you get feedback. For s.c.o, you have to send an e-mail and I never got an answer. Anyway, I have abandonned a long time ago the usage of my e-mail inbox to track issue progress.
• issues reported are quickly fixed
• you can even directly report issues on IRC (#metacpan) and get immediate feedback and fixes
• you can submit patches for MetaCPAN
• MetaCPAN has an API
• MetaCPAN is improving: frequent new features and appearance tweaks