Both the CLI CPAN module/tool itself and http://search.cpan.org/ are awesome to work with. I think every language should shamelessly copy them first, and try to improve upon them second.
It almost seems like Ruby/Python have been consciously reluctant to do so.
CPAN's success, as with Debian's, is not due to the technical infrastructure but rather the social infrastructure. There are plenty of ways to make packages not work at all, it's just that the Perl people don't do that.
(If you have ever read the CPAN source code, you would be surprised it works at all. Don't get me started on the various incompatible build systems, and what happens when your module's build system depends on a newer version of the build system.)
Haskell's Cabal is the technical model to steal. Don't let modules execute their own code unless they actually need to. 99.9999% of modules do fine with some sort of declarative interface, rather than actual code to do those things.
Yes, cabal is the thing to steal. Improving distutils is worthwhile, but a temporary stop gap, most fundamental issues cannot be solved from improving distutils. Distutils itself is only 10 000 LOC of bad code, without good API, and you can reuse most setup.py from a conversion step.
It does not do much ATM, except for the conversion step: it can generates a static description of the package from existing setup.py. It reuses distutils to build package, but it does so from the declarative file, meaning that the whole thing is not tied to distutils anymore: distutils becomes an implementation detail.
The CPAN works despite clunky code and competing implementations because the functional decomposition is sufficiently effective. (EUMM is some of the worst code in intent, design, and implementation I've ever read and used anyway.)
The CPAN software infrastructure only works for things that it was intended to do, it is very hard to make it do arbitrary things. If you want to find out what file to download from the BackPAN to get Foo::Bar 0.2, that's too bad, you have to download the BackPAN and index it yourself. Of course, there is no way to index things without evalling code regexed out of every file. (And there is no way to predict if "make install" will actually install Foo::Bar.)
Something CPAN couldn't easily do a few years ago was install to arbitrary directories. If you set the right environment variables, EUMM would sort of do the right thing. If you set different environment variables, sometimes MB would do the right thing. Eventually EUMM and MB were patched so that it almost always worked, and then local::lib was written to paper over the differences.
And of course, nothing requires the use of EUMM or MB, so if a package doesn't use it, you can't install it to your home directory.
Anyway, the EUMM is what you get when you write code to fix problems that people complain about. MB is what you get when you write specs to "fix" problems people complain about. Maybe someday we will have a build system that has a sane design and actually works.
Google is the de-facto rubygem search engine. If you don't know the real name of the gem, you Google for functionality or common name ([ruby prawn gem]), find a blog post, copy/paste the line that starts with "gem install" (gem install prawn), and then go back to whatever you were doing.
Eh, easy_install has been a sort of sticking point with me for a while. One of those things that makes me shake my fist at the sky and leaves me a bit baffled that I seem to be the only one pulling his hair out.
So far as I can tell there is no way for easy_install to do anything but install packages. I see an "upgrade" command but it seems to only work if I specify the package name, and I don't see any way to list what version of what is installed. I also don't see any way to remove packages.
In short, this means easy_install turns my system into a mystery grab bag of packages that I can't remove without fishing around in site-packages.
Unless of course I'm missing something, but if I'm missing something it certainly isn't obvious.
It almost seems like Ruby/Python have been consciously reluctant to do so.