If you have perl code to maintain and dependcies break, its not easy to use or at all intuitive. You run cpan, it tries to set itself up, 40 minutes later its trying to autoselect the same broken mirror. Is this going to go on forever?
Run again. Select repo, it kind of works.
Get 6 pages of build output and a broken install.
Its one of the first repos, a great idea, its just frustratingly obtuse.
> 40 minutes later its trying to autoselect the same broken mirror
Sounds like you're in a network with particularly misbehaved firewalls. The initial phase of the auto-setup is very fast, since it only checks file paths. The network part might be slow if some part of your network infrastructure messes with connections and cuts them without properly resetting, resulting in super long timeouts.
Not sure what you expect in such a situation.
> a broken install.
No you don't, unless it's an extremely old or shitty library you chose to dep on, since things build, run their tests, and only install when those pass. The 6 pages of output help you identify which tests failed and maybe why. Also, often test failures are simply because you have a system the author didn't write for, which hurts just as much with the other packaging systems.
Broken install = it didn't install. I had no idea why. I did get there after some hours of struggle . Part of the problem is the libraries on our system are everywhere.
Sorry I sounded cranky, truthfully I'm probbly just unfamiliar. I'm a developer not an admin, just want to install packages. We developers love the package systems and cpan pioneered a lot of it.
A great package manager goes a long was to helping a languages success.
I'm comparing to Gems, composer, npm, rpm which for what I've done with them work pretty flawlessly and easily.
cpanminus (cpanm) is an attempt to make a zero-configuration client
that automatically does the right thing for most users. It's also
designed to run well on systems with limited resources (e.g. a VPS).
It doesn't come with Perl, but it's easy to install.
It integrates easily with local::lib.
> I had no idea why. ... Sorry I sounded cranky, truthfully I'm probbly just unfamiliar.
Yes. CPAN does a lot to help the user and gives a lot of information, but all that information truly does contain 99% of what you need.
It progresses in phases (prep, make, test, install) just like most other make-based software (99% of the stuff installed on your linux boxes) and after each phase it will say "<phase> OK"/"<phase> NOT OK", so you only have to read for that, then scan upwards to see what errors you got from gcc or whatever. In other words, and i'm not trying to be mean, but: You only have to read what is on your screen.
As for "Gems, composer, npm, rpm", i know that the three non-npm ones don't run tests on install (npm probably doesn't either), so you might be conflating "flawless and easily" with "system incompatibilities are found at runtime, instead of install time". I.e. it's highly likely that what you like of them isn't that they've progressed beyond CPAN.pm, but that they've yet to catch up to it.
At a previous job perl was used everywhere. As a language, it's quite nice. CPAN is horrible, though. No staging/stable/whatever versioning, new modules requires updating versions of existing modules which frequently broke - it's just not something that's enterprise friendly.
I tried but failed to find a company that would support and curate a subset of CPAN modules properly. Does one exist now?
There are multiple tools to do this on your own, with CPAN::Mini and friends, or Carton.
I also don't know how long it's been since you last tried, but cpantesters and the other odds and ends of the ecosystem have helped tremendously in reducing published bugs. ( http://matrix.cpantesters.org/?dist=System-Command%201.115 )
Checkout Pinto, http://perlmaven.com/pinto-tutorial, which allows you to host your own CPAN mirror and have stacks. So you could have a "development" stack and a "production" stack, or a "perl-5.8" stack and a "perl-5.16" stack. Whenever you add or upgrade a module, it only affects one stack.
