6 ms·

CPAN is 20

183 points by neilbowers 11y ago

stevebmark 11y ago
How old is metacpan, the site that makes cpan useful?
- smonff 11y ago
  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 11y ago
    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. :)
- mst 11y ago
  Prior to metacpan there was search.cpan.org, and that existed for a -lot- of years by now.
jph 11y ago
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!
Isamu 11y ago
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 11y ago
  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 11y ago
    I was unaware of the distributed library testing community. How does it work, pray tell?
    - daxelrod 11y ago
      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
    - Mithaldu 11y ago
      Quite short version: Almost every perl module has a set of test scripts that can usually be called up by running make test. This happens by default when installing something with CPAN.pm. The output of this can be captured by CPAN.pm and sent on to a receiving server. Said server can be anything, but in almost all cases is the cpantesters metabase server, which integrates the result into a database which contains and summarizes the results of tests for libraries, by library version, operating system and perl version. In addition to people configuring their CPAN.pm that way and sending reports for everything installed, there are also many people who have set up servers that work on testing the newest version of every library uploaded to CPAN.
smonff 11y ago
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 11y ago
  Seems to me that CPAN would still have a ton of things to teach to new repositories but seems few people look at it.
deleted 11y ago
[deleted]
sparaker 11y ago
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.
dinesh_babu 11y ago
who else read it as CSPAN?
Hosohoso 11y ago
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.
- IndianAstronaut 11y ago
  In that sense CRAN is better maintained. It has to keep up with the changing R environment or it doesn't get included anymore IIRC.
- Mithaldu 11y ago
  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 11y ago
    Web development.
    - Mithaldu 11y ago
      At that time CGI::Application was way out of alpha and actively maintained.
      - Hosohoso 11y ago
        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.
        11y ago
gauravphoenix 11y ago
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 11y ago
  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/main.c?id=1b80fb16c22db72457d7a456ffbf1f70a8dfc0a5 https://anonscm.debian.org/cgit/dpkg/dpkg.git/plain/main/mai...
tmaly 11y ago
I have used CPAN for years, its amazing. I finally gave back three years ago, and I contributed a module.
lugus35 11y ago
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 11y ago
  > 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/cpanm http://search.cpan.org/~miyagawa/App-cpanminus-1.7039/bin/cp... https://github.com/chromatic/CPAN-Dark https://github.com/chromatic/CPAN-Dark http://search.cpan.org/~jhthorsen/App-git-ship-0.19/lib/App/git/ship/perl.pm http://search.cpan.org/~jhthorsen/App-git-ship-0.19/lib/App/... http://www.perlmonks.org/?node_id=1028999 http://www.perlmonks.org/?node_id=1028999 http://search.cpan.org/~sunnavy/Shipwright-2.4.41/lib/Shipwright.pm http://search.cpan.org/~sunnavy/Shipwright-2.4.41/lib/Shipwr... http://perlbrew.pl/ http://perlbrew.pl/
  - ionelm 11y ago
    `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).
aikah 11y ago
When a language dies an entire knowledge base is lost. I hope this won't be perl's fate.

CPAN is 20

183 points by neilbowers 11y ago

stevebmark 11y ago

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

smonff 11y ago
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 11y ago
  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. :)
mst 11y ago
Prior to metacpan there was search.cpan.org, and that existed for a -lot- of years by now.

jph 11y ago

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!

Isamu 11y ago

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 11y ago
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 11y ago
  I was unaware of the distributed library testing community. How does it work, pray tell?
  - daxelrod 11y ago
    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
  - Mithaldu 11y ago
    Quite short version: Almost every perl module has a set of test scripts that can usually be called up by running make test. This happens by default when installing something with CPAN.pm. The output of this can be captured by CPAN.pm and sent on to a receiving server. Said server can be anything, but in almost all cases is the cpantesters metabase server, which integrates the result into a database which contains and summarizes the results of tests for libraries, by library version, operating system and perl version. In addition to people configuring their CPAN.pm that way and sending reports for everything installed, there are also many people who have set up servers that work on testing the newest version of every library uploaded to CPAN.

smonff 11y ago

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 11y ago
Seems to me that CPAN would still have a ton of things to teach to new repositories but seems few people look at it.

deleted 11y ago

[deleted]

sparaker 11y ago

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.

dinesh_babu 11y ago

who else read it as CSPAN?

Hosohoso 11y ago

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.

IndianAstronaut 11y ago
In that sense CRAN is better maintained. It has to keep up with the changing R environment or it doesn't get included anymore IIRC.
Mithaldu 11y ago
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 11y ago
  Web development.
  - Mithaldu 11y ago
    At that time CGI::Application was way out of alpha and actively maintained.
    - Hosohoso 11y ago
      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.
      - 11y ago

gauravphoenix 11y ago

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 11y ago
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/main.c?id=1b80fb16c22db72457d7a456ffbf1f70a8dfc0a5 https://anonscm.debian.org/cgit/dpkg/dpkg.git/plain/main/mai...

tmaly 11y ago

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

lugus35 11y ago

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 11y ago
> 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/cpanm http://search.cpan.org/~miyagawa/App-cpanminus-1.7039/bin/cp... https://github.com/chromatic/CPAN-Dark https://github.com/chromatic/CPAN-Dark http://search.cpan.org/~jhthorsen/App-git-ship-0.19/lib/App/git/ship/perl.pm http://search.cpan.org/~jhthorsen/App-git-ship-0.19/lib/App/... http://www.perlmonks.org/?node_id=1028999 http://www.perlmonks.org/?node_id=1028999 http://search.cpan.org/~sunnavy/Shipwright-2.4.41/lib/Shipwright.pm http://search.cpan.org/~sunnavy/Shipwright-2.4.41/lib/Shipwr... http://perlbrew.pl/ http://perlbrew.pl/
- ionelm 11y ago
  `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).

aikah 11y ago

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