
The end of an era: Saying goodbye to search.cpan.org - jasonjayr
https://log.perl.org/2018/05/goodbye-search-dot-cpan-dot-org.html
======
jedberg
Now _this_ is you how EOL a beloved product. By working with an OSS
replacement such that the transition is transparent.

Super thanks to the team for the CPAN search (it was a lifesaver many times
for me in the past!) as well as for their awesome transition plan.

~~~
X-Istence
Same way that PyPI.org (Warehouse) replaced the old pypi.python.org codebase?

Mostly transparently?

~~~
saghm
Didn't that transition not go very smoothly? I seem to remember having nowhere
to download packages stuff at work when they turned the old system off (I
think due to the new system not being able to handle the load, but I could be
wrong)

~~~
jsmeaton
There were issues with the CDN and redirects[0] for a couple of hours when
they flicked the switch. Still, I think it was a very successful transition.

[0]
[https://status.python.org/incidents/1y1f44q6srh2](https://status.python.org/incidents/1y1f44q6srh2)

------
portmanteaufu
From the article:

> In recent years maintenance has become a burden. Most of the site is running
> 2005 era Perl code. Luckily, there is now a viable alternative:
> MetaCPAN.org. The MetaCPAN team has been getting ready for the transition
> and is nearly ready to take over. Shortly, a link will be added to all pages
> on search.cpan.org to inform users of the upcoming change. After about a
> month, all traffic will be redirected to the equivalent MetaCPAN page.

Existing search.cpan.org links will continue to work after the transition.

~~~
Klathmon
>Existing search.cpan.org links will continue to work after the transition.

They should get a lot more credit for this. Linkrot sucks, and I'm sure the
effort that was required to pull off maintaining those links is going to pay
off greatly for many for years to come.

~~~
perigrin
They actually have had the existing URLs working via `search.mcpan.org` for
several years now, this is really just a matter of dropping the `m`.

~~~
saghm
I'm not very familiar with the Perl ecosystem, but that would be an entirely
different domain; was the server behind it maintained by the the MetaCPAN
people, or the cpan.org people?

~~~
haarg
It has been maintained by MetaCPAN people. Since this transition has been
planned, extra work has been put it to make the redirects more comprehensive.

------
kyoob
This is truly a down moment, to be sure, but it's pretty telling that the site
became too hard to maintain because it's written in old Perl.

I'm not a Perl hater. I like Perl! I got my start in Perl and spoke at a
YAPC::NA a few years ago. It's telling, is all I'm saying. It tells us
something.

~~~
mst
It tells us that a solo maintainer of a large project - with no assistance
from the community possible, because closed source - trying to do it in his
spare time, will eventually result in a massive accretion of technical debt.

It's a testament to Graham's productivity that he was able to keep maintaining
it for so long in spite of those disadvantages, and says very little about
perl.

~~~
ajpocus
Does it necessarily follow that a solo dev, working on a project in their
spare time, will accrue massive technical debt? I'm honestly asking, as a solo
dev that works on projects in my spare time. If it is the natural progression,
how can it be avoided?

~~~
wpietri
I don't think so.

Personally, I'm prone to taking on technical debt when under time pressure or
feature pressure. I think of it like my house: if I'm too busy, I get sloppy
and leave messes. If I stay busy for too long, the messes stack up.

One complicating factor, though, is the age of the code base is a factor, too.
Keeping up with new runtimes, new frameworks, and new ways of doing thing
takes time. This is especially a problem with things built in the new hotness,
because there the culture is one of rapid iteration. So if we really want side
projects to last, I think we have to choose boring technology:
[http://mcfunley.com/choose-boring-technology](http://mcfunley.com/choose-
boring-technology)

------
avar

        > Luckily, there is now a viable
        > alternative: MetaCPAN.org[...]
    

This is somewhat of a revisionist history. MetaCPAN has been around in a form
where it's been a good search.cpan.org replacement since 2012 at least, but
for some reason that whatever set of people that run perl.org haven't wanted
to switch serch.cpan.org over.

I'm very grateful to the effort of Graham Barr in creating serch.cpan.org, and
fully understand that he may have his own reasons for never open sourcing it,
and I respect that.

But at the same time it's really odd that the Perl project has been willing to
run proprietary code on one of its main landing pages for almost a decade when
a viable open source alternative has been available.

~~~
jacoblambda
From what I have been able to gather, MetaCPAN was the planned replacement for
search.cpan.org and the reason it took forever to transition was to guarantee
a perfect handover and minimal to no issues(linkrot, API problems, etc) upon
the shutdown of the search.cpan.org servers.

They spent a good deal of time making a perfect drag and drop replacement and
I think it went very well.

------
upbeatlinux
Many thanks to Graham!

search.cpan.org was invaluable during my college senior projects in 2002 and
much more so in my first gig. Back then I couldn't imagine being a Perl dev
without it.

FWIW I can't imagine a better way to transition a project. Kudos to the
MetaCPAN team!

------
debacle
It's paradoxical that Perl still runs so much of the Internet, but rarely gets
any credit.

------
ninjakeyboard
Thanks Graham. Perl was the first language I worked with professionally. It
got me my start into software development all those years ago. Cpan was my
first look at what dependency management might look like.

------
staunch
Graham Barr did the world a huge service by creating and running
search.cpan.org. I used it for many years, across many projects. Thank you
Graham!

And it's nice that there exists a great replacement in metacpan.org

------
tootie
This was the granddaddy package manager. Before gem or npm or maven or pip. It
was the gold standard for sharing open source libraries and was the best
reason for using Perl for a long time.

~~~
perigrin
To be fair this was just _a_ search engine for the package archive. The
archive, it’s several clients, and alternative search engine, are still doing
fine.

------
nopacience
cpan.org is great! it will be missed!

a couple days ago searching for some tool, i wanted to check some source at
npmjs and to my surprise npmjs does not have a "download any-module.tar.gz"
and neither has an option to "view the source" code like old cpan does.

i went to #nodejs to ask for help and guys there told me to install "npm" to
download the source from npmjs module i wanted to see. NOOOO... i dont want to
install npm, i just want to see how it was done. Cant i just click "download
source" at the npm page ? NO. Cant i just click "view source" at the npm page
? NO. Just install npm and install the module so you can see the code... COME
ON....

cpan.org so old and still so up-to-date!

perl so old and still so up-to-date!

------
moltar
Finally Google search results will point to the better site. It was always so
frustrating to google anything Perl related and get search.cpan.org over
metacpan.

~~~
kbenson
One of the only pure _usability_ [1] wins from switching to DDG a few months
back is that metacpan was always considered a better better/higher placed
result. Of course, that only makes sense... [2]

1: It's nearly impossible to compete with Google when you aren't collecting
every bit of data. That said, the reasons to switch remain compelling even
months later.

2: [https://metacpan.org/release/DDG](https://metacpan.org/release/DDG)

~~~
perigrin
It wasn’t always. Kind words were said and `!cpan` was switched early on.

------
theclaw
Sorry to see search.cpan.org go, I don't write much perl nowadays so only just
discovered metacpan, which seems like a big step forward. It is appropriate
that there would be more than one way to do it.

Still, I pored over search.cpan.org for many long hours as a kid building
summer projects. The ability to browse the package source was invaluable to me
on a dial up link. Here's to all those that worked on it.

------
ben1040
TIL it was originally hosted at WashU, my alma mater.

I guess it was probably in the same server room as wuarchive, which at its
peak in the 90s was rumored to represent 10% of the traffic on the internet.
Was cool to look through the glass into the server room in the engineering
school, and see the lights blinking like crazy on the RAID array attached to
wuarchive's server.

------
seorphates
Countless hours saved. Countless discoveries made. Goodbye search.cpan.org..
It was a fun run.

------
brightball
Wow.

I'm still thankful to that site for helping me find the incredibly useful
SSH::Batch library. Whether you're using Perl or not, it's an incredibly
helpful command line tool for simple operations on multiple machines.

Never would have found it without search.cpan.org.

------
esaym
Since metacpan.org has been around, I've always hated search.cpan.org.

Case in point, at a previous employer, a contractor was tasked with
integrating Jira with an existing hacked together monitoring system in order
to 'automatically' create trouble tickets. Not hard to do, but the problem is
he just googled 'perl soap' (since the jira api was SOAP). Which lead to a
soap package on cpan.org, and it (the google index) didn't even show the
latest version but a tarball version from 2001 (this was in 2012) which he
installed manually.

Fast forward a few months and randomly the tickets that this perl script was
creating in Jira were sometimes only have filled out and full of gibberish. It
was quite the head scratcher to figure out, but in the process I noticed the
super old SOAP package installed, I updated it via cpanm and all the problems
went away. Apparently the old soap version didn't even have support for UTF8
and that was the issue (the script actually copied comments from employees in
the other monitoring system and some new employees were given new laptops with
Win8 that for what ever reason was sometimes using the UTF8 version of non
breaking space chars...)

~~~
labster
This doesn't sound like a reason to hate search.cpan.org.

To me, it sounds like your contractor was awfully lazy or underinformed. They
didn't do the basic level of due diligence to determine if they had the most
recent version of software -- nor were they even aware of the module
installers. I don't use Python or Node.js all that much, but at least I'm
aware of pip and npm.

------
testplzignore
Not a knock against the people who created metacpan, but it is interesting how
much faster search.cpan.org is than metacpan.org when displaying basically
identical information on module pages. The page load time is consistently
about 5 to 10 times faster on search.cpan.org on the first load of a page,
though subsequent loads are faster on metacpan, so they must have some caching
in front.

~~~
combatentropy
The new site's search results are noticeably slower. On search.cpan.org,
searching for "cgi" took 90 milliseconds, whereas the new site takes 1.25
seconds. I tried several times.

~~~
kbenson
They likely don't search the entirely same set of data (that is, cpan's search
is likely a subset of metacpan's search). Also, metacpan groups results by
package, which cpan returns individual modules (that is, you might have
multiple results, one for each module in a package that matches in some
manner). Page load speed isn't everything, and the the very quick search
suggestions from the metacpan search that on a regular basis get me exactly
what I want without a full search page load more than make up for it for me.

------
jandrese
2005 era Perl is still Perl 5. It might not be using the more modern
extensions, but it's not like it was written in Perl 3 or something.

I wonder if they were building the pages in the CGI module directly? That was
pretty common back then but has been depreciated for a few years now, although
it still works for now.

~~~
jasonjayr
In 2005 mod_perl was a pretty popular way to build a perl site. It's almost
certainly using mod_perl under the hood.

~~~
ccozan
I still have the Mason book, can see it in my shelf in front of me!

------
znpy
I was wondering: given that

\- Perl6 is quite a different language from Perl5

\- I am aware that there is an enormous amount of code written in Perl 5

Has anyone of you started transitioning to Perl6 ? If so, what's your
experience/opinion ?

~~~
lizmat
I've written a blog post about that: [https://www.perl.com/article/an-open-
letter-to-the-perl-comm...](https://www.perl.com/article/an-open-letter-to-
the-perl-community/)

The modules implemented so far:
[http://modules.perl6.org/t/CPAN5](http://modules.perl6.org/t/CPAN5)

I'll also be giving a keynote on this subject at The Perl Conference 2018:
[https://perlconference.us/tpc-2018-slc/session/the-state-
of-...](https://perlconference.us/tpc-2018-slc/session/the-state-of-the-cpan-
butterfly-plan-2/)

If you want to keep up to date on happenings in the Perl 6 world, please
checkout the Perl 6 Weekly:
[https://p6weekly.wordpress.com](https://p6weekly.wordpress.com)

------
Improvotter
I originally thought they meant it was going to be retired on the May 25
instead of June. I was like wut? How can GDPR do this?

------
vgy7ujm
Metacpan is great, why continue with a double effort that needs a rewrite. It
has served the community well for many years.

------
examancer
I misread the headline. I was really worried I wouldn't be able to search
C-SPAN archives anymore. I'm glad I can still find old clips of bonehead
senators trying to grandstand at hearings.

------
kizer
Sad news. Hopefully a replacement will fill its place and provide
comprehensive public access to our government broadcasting network's archives.

~~~
JadeNB
> Hopefully a replacement will fill its place and provide comprehensive public
> access to our government broadcasting network's archives.

Is this a joke? That's not what CPAN is about. For what CPAN is for, there
already _is_ a replacement, MetaCPAN.

~~~
vxNsr
Dude half read the headline and nothing else. He saw CSPAN.

------
jedisct1
For people under 40: "Perl" refers to a script interpreter that used to be
popular in the 90's.

~~~
Moto7451
You might be surprised at how many folks under 30, such as yours truly, use
Perl day in and out. I know about twenty others through my work and there are
folks who float in and out of YAPCs.

------
rurban
Also goodbye illguts then.

Illustrated guts is the description of the perl5 internals, in html and
images. Metacpan still does not allow displaying it and I won't pay for
hosting services.

Static GitHub pages maybe, but how stable will that be, and it's another link
away from the primary content. They knew of this problem for years.

~~~
vgy7ujm
Maybe get it into (perldoc?) perl.org if possible?

~~~
rurban
I told them 5 years ago already. Didn't happen. So far all my suggestions were
declined. And recent maintainerships made it much worse.

This move off search.cpan.org was cooking up for the last decade, explained in
the post.

