

CPAN is 20 - neilbowers
http://blogs.perl.org/users/neilb/2015/08/cpan-is-20.html

======
smonff
CPAN is an awesome tool. First, this is a good way to avoid to reinvent the
wheel. Second, it's companion, CpanTesters community platform, gives to the
authors a damn simple way to test their modules on a huge variety of OS and
architectures. These tests are public and will help people to choose
distributions according to their needs and quality exigences. Third, it
encourage to test and upload modules at early stages of the development: it
makes possible to simplify the development process by retrieving test results,
and be sure the modules will be usable on various OS, even if they are quite
old or uncommon. It's almost disappointing sometimes how for any task you need
to achieve, each time there is an existing module ready to be _use_.

~~~
riffraff
Seems to me that CPAN would still have a ton of things to teach to new
repositories but seems few people look at it.

------
Isamu
A good time to acknowledge that CPAN was a very influential example for
internet libraries that came afterward.

I got a lot out of it for years, time to say thanks! You guys in the Perl
community were awesome and still are!

A shout out to CTAN too!

~~~
Mithaldu
To be honest, it still is. Many of the other ones have yet to catch up with
CPAN in terms of richness in eco system and breadth of offered features.

For example, i know no (and i may be ignorant) language that has a distributed
library testing community.

~~~
igravious
I was unaware of the distributed library testing community. How does it work,
pray tell?

~~~
daxelrod
Volunteers with lots of different perl versions and OSes run software that
monitors CPAN for new uploads, and then automatically downloads them and runs
their automated tests, and uploads the results.

Here's more on CPANTesters:
[http://wiki.cpantesters.org/wiki/WhatIsCPANTesters](http://wiki.cpantesters.org/wiki/WhatIsCPANTesters)

And here's an example of the results for a popular module:
[http://matrix.cpantesters.org/?dist=Moose+2.1600](http://matrix.cpantesters.org/?dist=Moose+2.1600)

------
lugus35
For libraries:

in Perl : there is really one way to do it, use CPAN.

in Python : there's more than one way to do it : pth, eggs, setuptools, pip,
wheel, distutils, easy_install,...

[http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-
everywhere/](http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/)

~~~
pyre
> in Python : there's more than one way to do it : pth, eggs, setuptools, pip,
> wheel, distutils, easy_install,...

> pip, wheel

Package formats: egg, wheel

Packaging/Install libraries: setuptools (incl. easy_install), pip, distutils

Install method: pth

It looks less daunting when you don't make every item look like a replacement
for itself. I notice that under Perl you don't list ".tar.gz" ".tgz"
".tar.bz2" and ".tar.xz" in the list of "ways to do it."

Also:

* Wheels are (at least officially) considered the way forward. Support for other formats is legacy. Yes, this is less ideal than keeping a simple package format for 20 some odd years, but Python also really didn't take off in popularity until ~2002 despite being almost as old as Perl. Also, it makes sense to improve the state of things when necessary (e.g. creating wheels vs. sticking with eggs) rather than doing nothing.

* distutils was a fork of setuptools that has since been merged back into setuptools. Counting it twice doesn't speak to the current state of things.

* easy_install is the installation command that is _part_ of the setuptools package, so including it in the list is counting the same thing twice. (I'll notice that you didn't include any CPAN wrappers as "different ways to do it.")

> in Perl : there is really one way to do it, use CPAN.

[http://search.cpan.org/~miyagawa/App-
cpanminus-1.7039/bin/cp...](http://search.cpan.org/~miyagawa/App-
cpanminus-1.7039/bin/cpanm)

[https://github.com/chromatic/CPAN-Dark](https://github.com/chromatic/CPAN-
Dark)

[http://search.cpan.org/~jhthorsen/App-git-
ship-0.19/lib/App/...](http://search.cpan.org/~jhthorsen/App-git-
ship-0.19/lib/App/git/ship/perl.pm)

[http://www.perlmonks.org/?node_id=1028999](http://www.perlmonks.org/?node_id=1028999)

[http://search.cpan.org/~sunnavy/Shipwright-2.4.41/lib/Shipwr...](http://search.cpan.org/~sunnavy/Shipwright-2.4.41/lib/Shipwright.pm)

[http://perlbrew.pl/](http://perlbrew.pl/)

~~~
ionelm
`easy_install` is not a library per se, it's a binary offered by setuptools.

> distutils was a fork of setuptools

This is incorrect. Setuptools is an extension of distutils (it patches and
extends distutils to have additional functionality). Distribute was a fork of
Setuptools that has been merged back into Setuptools.

Also, `pth` is not a installation method - it's merely a way to customize the
import system. It's a very scary feature as it allows one to execute arbitrary
code (that can reside in the `.pth` file) when import paths are being set up
(when the `site` module is being initialized).

~~~
pyre
> `easy_install` is not a library per se, it's a binary offered by setuptools.

I thought that I clarified that in my post, but if you could tell me what was
confusing, I'll use that to inform future discussions I have on this.

> This is incorrect. Setuptools is an extension of distutils (it patches and
> extends distutils to have additional functionality). Distribute was a fork
> of Setuptools that has been merged back into Setuptools.

Correct, and one reason why the landscape has been confusing for a while
(confusion between distutils/setuptools/distribute). Thankfully distribute has
been merged back into setuptools.

> Also, `pth` is not a installation method

You're right. It's a way to customize the import system, but it's "main" usage
in the wild is during installation/setup. The main place that I've seen it
used is with easy_install + eggs (IIRC).

------
sparaker
I think it was the first better done package managers. Saved the problem of
installing modules on cross platforms. Most of the time it works without a
hiccup. For a perl developer CPAN is a friend.

------
jph
Congratulations! I recall when it debuted and it was a huge accomplishment. 20
years onward and it's still a huge accomplishment, especially testing on so
many systems. Thank you to all the maintainers!

------
Hosohoso
My experience from a decade ago was different than most here, I had not so
much luck with CPAN.

Many libraries and projects, but most of them alpha or abandoned. It took a
lot of time to find stuff that was built well enough for production and was
still maintained.

~~~
Mithaldu
What exactly were you looking for? Which libraries did you find that were
alpha or abandoned?

It's highly likely that your experience was simply due to the problem domain
you were looking at. If i were to look at something i work with, 3d graphics,
my results would look much the same as what you said.

That doesn't mean all of CPAN's like that though.

~~~
Hosohoso
Web development.

~~~
Mithaldu
At that time CGI::Application was way out of alpha and actively maintained.

~~~
Hosohoso
I prefer using libaries instead of developing everything on my own, so usually
I use 10-20 libraries for a project beyond a web framework, e.g. credit card
management, HTTP library,.... YMMV and if a web framework is all you need,
hurray to you.

~~~
Mithaldu
I asked for "What exactly were you looking for? Which libraries did you find
that were alpha or abandoned?"

You only said "Web development."

Now you're addressing completely different problem domains, so if you don't
like my answer, than that is because your initial answer to my question wasn't
very clear. Were my questions unclear?

~~~
Hosohoso
Not sure why you agressivly attack me.

But sorry. This was more than a decade ago, I've done dozens and dozens of
projects since then with Java, C, Ruby, Python, Clojure, Scala, Javascript,
Coffescript and Typescript and more, so I can't remember 'exactly' what
libaries I was using more than 10 years ago in some Perl projects.

"Now you're addressing completely different"

I beg to differ, in my book credit card processing during e-commerce checkou
and accessing backend services with HTTP are in the problem domain of 'web
development', but it might be different for your 'web applications'.

~~~
Mithaldu
I'm not attacking, i'm trying to figure out your case, because i occasionally
hear people voicing a sentiment as in your original post, but _never_ with
actual detail. I'm just curious and wish to know more about this. :)

And sure, i didn't really expect you to remember what you did find. But while
your response of "web development" does include credit card and http stuff, it
only does so roughly. Many many web apps don't use either.

That said, at that time both LWP and Business::CreditCard were in what looks
like sensible states: [https://metacpan.org/release/GAAS/libwww-
perl-5.803](https://metacpan.org/release/GAAS/libwww-perl-5.803)
[https://metacpan.org/release/IVAN/Business-
CreditCard-0.28](https://metacpan.org/release/IVAN/Business-CreditCard-0.28)

Did the search interface at the time not surface them for you, or were they
incompatible with what you were trying to do?

------
gauravphoenix
Are there package formats older than CPAN? Which is the oldest one?

I did some digging and it seems that RPM, DEB etc were created after 1993 so
perhaps CPAN could be father of packaging formats.

~~~
laumars
CPAN was also created after 1993, hence it being 20 years old :p

I don't know when the Debian package format was first created, but dpkg was
rewritten in C back in '94[1], so it would predate CPAN. However the real
genius of package managers is dependency resolution and the central software
repositories - both of which likely came a little while after dpkg. I'd be
interested to read more on the history of Debian's package management though -
if anyone does find a reference.

[1]
[https://anonscm.debian.org/cgit/dpkg/dpkg.git/plain/main/mai...](https://anonscm.debian.org/cgit/dpkg/dpkg.git/plain/main/main.c?id=1b80fb16c22db72457d7a456ffbf1f70a8dfc0a5)

------
stevebmark
How old is metacpan, the site that makes cpan useful?

~~~
smonff
According to their about page, it is 5 years old.

 _We are a relatively young open source project. In November 2015, MetaCPAN
will be 5 years old. It 's old enough to have become an important and well
utilized part of the Perl world, but it's also young enough to have lots of
room to evolve. As you will see we have many ideas and encourage more
suggestions._

~~~
oalders
Yep, that's correct. I still remember when I registered the name. It has grown
far beyond anything I had imagined.

The whole CPAN ecosystem (CPAN, CPAN Testers, search.cpan.org, metacpan.org
etc) involves a lot of people and a lot of resources. It's not just open
source software -- it's open source "software as a service". So you get to
push some code and also worry about uptime!

Lots of volunteers and more than a few sponsors make sure the ecosystem keeps
on ticking. My thanks to all of them. :)

------
tmaly
I have used CPAN for years, its amazing. I finally gave back three years ago,
and I contributed a module.

------
aikah
When a language dies an entire knowledge base is lost. I hope this won't be
perl's fate.

------
dinesh_babu
who else read it as CSPAN?

