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!
For example, i know no (and i may be ignorant) language that has a distributed library testing community.
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/
> 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...
https://github.com/chromatic/CPAN-Dark
http://search.cpan.org/~jhthorsen/App-git-ship-0.19/lib/App/...
http://www.perlmonks.org/?node_id=1028999
http://search.cpan.org/~sunnavy/Shipwright-2.4.41/lib/Shipwr...
* In the Python world, pip replaces/supplants/simplifies away easy_install much in the same way that cpanm/cpanminus made things much easier than the regular cpan command, or even cpanplus (at least in my experience). I feel like listing of "CPAN" as a whole, while breaking out "pip" and "easy_install" is disingenuous in light of this.
* CPAN is just the distribution network (plus all of the meta stuff like search.cpan.org, metacpan, cpantesters, etc). Python also has a single distribution network: The Python Package Index (aka PyPI / "the cheeseshop").
* Talking about distutils/setuptools/distribute is the same as talking about many of the tools that are used to manage Perl packages/modules (I can't recall their names off the top of my head, but there are at least 2 or 3 of them, and they all generate their own Makefiles/etc for doing things). It's possible that these have been simplified away in the last few years (since I've been in Perl-land), but the legacy is still there (much like the legacy of Python's various distribution/packaging setup libraries).
I will admit, that as a whole, I like CPAN better than PyPI, if only for the fact that it's easy to fetch the author/package/etc lists as a gzip-ed text file whereas most tools interacting with PyPI are basically screen-scraping the website (rather than having a simple/easy api).
> 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).
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.
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.
I did some digging and it seems that RPM, DEB etc were created after 1993 so perhaps CPAN could be father of packaging formats.
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...
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.
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. :)
