Is cpanminus the future?
Yes.
Miyagawa's excellent cpanminus is described as follows:
cpanminus is a script to get, unpack, build and install modules from CPAN.
Why? It's dependency free, requires zero configuration, and stands alone -- but it's maintainable and extensible with plugins and friendly to shell scripting. When running, it requires only 10MB of RAM.
Recently on reddit, someone asked how to easily install something with CPAN.pm. Here was the example they gave:
# python
sudo easy_install yadda
baddabing...
badaboom...
installed!
# perl
cpan install yadda
Do you want to do this? [yes]
Would you like to do that? [no]
Are you sure? [no]
And they asked "Is there any way to just install the darned thing with CPAN like easy_install?"
Frankly, we're so used to running around to the front of the car and crank-starting it that we've forgotten that other people find this annoying.
I imagine that many experienced users are going to want to pay closer attention to what's going on, but for the masses, removing barriers to entry is a good thing. This is why I'm so happy to see Adam Kennedy's competition between Mojolicious and Dancer, Week 1 and Week 2. This should drive some healthy competition between two frameworks designed to be lightweight and easy to use. Catalyst is fantastic, but I probably wouldn't point a newbie to it.
So to have a relevant digression, game designers focus on something they call churn. Churn is the turnover rate of players. To have a successful game, you have to have more new players come in than existing players leave. They have to pay attention to new players because there's too much money riding on it. I think the Perl community sometimes forgets that it's OK to do things which attracts new people to the language.
¡Viva la revolución Perl!
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
Totally agree. One thing I'm not clear on, though, if cpanminus is the future, what is its future?
brian d foy recently asked what a new CPAN client could do, saying that he and David Golden were beginning to seriously discuss that project.
Miyagawa expressed interest there, and then earlier this week announced that he, too, is working on a next-generation CPAN client built on top of cpanminus, which he codenames "jam".
Are they really (as it seems) both working on two different clients at the same time, or are they actually collaborating? If they aren't collaborating, how are their goals and approaches different? What does that mean for the future?
What has this to do with CPAN?
It's entirely a module installation issue. If a module needs some options, it has to ask. On python it either just works (no questions asked) or you have to patch it. python is seriously broken, perl not at all. parrot tried but also failed, emacs also got it right. cpanminus only solves the slow dependency checking problem by cutting down the downloading and external checks.
Providing packages on python is effectively impossible, because the src build path is baked into the configuration, so you have to download src into the very same dir if a binary package like DateTime e.g. does not install. I stopped patching our python module INC paths. It's like in the early ActivePerl days, where you had binary packages only.
My experience in this area is that Perl modules do two things that can make it harder to install stuff. First of all we all write tons of tests, the Perl testing culture is very strong, but quite often there are buggy tests or tests that make assumptions about platform/OS/setup etc. that are just not universally applicable. As a result in the past year most of the trouble I've had installing stuff from CPAN have been 'false positive' test failures. As we get better at writing good cross platform tests this problem will diminish.
Also, cpanminus makes it easy to install a module without running tests. Honestly, stuff like ruby gems mostly don't run any tests. I know its a mental shift for us, because Perl community encourages everyone to think of themselves as a developer, but really we might want to consider recommending people install with notest when their platform is well known, etc.
Another thing of course is that CPAN authors use CPAN and typically our code has deeper dependencies then what I see for most python, php or rails applications. By extending the dependency chain this trouble is a risk we run.
Really it does challenge what we see as out community. Are we all developers, including admins that just want to install bits and see them work? If so we need to think deeply about how we are going to communicate that and ease the learning curve.
I second the comment that one of the most serious issue with the CPAN install process are broken tests.
As I use Windows as my primary development platform, I'm tired of seeing tests failing because authors expect paths using '/' instead of Windows default '\'.
For me, it's easy to spot that and tell CPAN to install the module despite these failures, but for a rookie it probably wouldn't be the case.
Although I personally never had any issues with the regular CPAN client myself, I can see the value of something like cpanm.
However, it's important to keep and maintain the regular CPAN client around as cpanm currently lacks some features (right now, I'm behind a restricted, authenticated, proxy and couldn't get cpanm to work, while the regular CPAN client works just fine).
Nice illustration of car cranking. When I first had to use PHP's PEAR client and rubygems a few years ago, I thought to myself, "Gee, is that it? Too simple, no configuration, only a few options... must be a toy."
Anyway, it's nice for the community to have both the practical, simplest-thing-that-could-work approach with cpanminus, and the idealistic, grand-design-big-picture approach that brian d foy et al is about to work on.
One you can use today, the other maybe in 2 years at the earliest. Sorta like what we have now with Perl 5 vs 6.
I never got used to CPAN.pm / CPANPLUS.pm. I've always hated the defaults with a passion. cpanminus has much better defaults.
Adam: i can't 100%-clearly state this yet, but the cpanminus future is that, i will freeze the feature development with 1.0 release in a few days hopefully, and will refactor/add a scriptable API with 1.1 release so that I can start coding a new client "jam" on top of it, and that's it.
I talked with brian d foy and BooK at Vienna, and if "jam" does what they want, they won't develop a new CPAN client -- because obviously, that's a duplicated work and totally a waste of both our time.
Reini:
But the problem is that a) there are many questions that Makefile.PL/Build.PL could ask but actually don't make many sense for most users and b) error test failures that don't really matter much but just confuse users.
cpanminus just assumes everything as a default (
PERL_MM_USE_DEFAULT=1and equivalent) and in the case of test failures it gives users a chance by asking "Do you really care this test failure?" which defaults to "yes" because well, as a developer, i believe testing is important.You're right that if the module depends on external dependencies e.g. XML::LibXML against libxml, that's totally another problem. However, even if that's the case, when xml2-config is in your PATH there's no user manual configuration required. And in cases when that doesn't work, there's a --interactive option that you can make the configuration interactive.
cpanminus doesn't invent any new way to install modules. It's just providing a sane (really sane) defaults that work for 99.9% of the modules for many people, while leaving the options to make it chatty and interactive
Nilson: doesn't setting
HTTP_PROXYenvironment variable work? cpanm uses LWP (if installed) and setsenv_proxyoption to make the proxy env work -- I'd love to get your feedback.In my opinion, TIMTOWTDI and portability are the biggest contributors to what makes CPAN installation hard.
For example, do you want to use binaries to uncompress the distribution tarball or perl modules? (Are you on a system that has no tar? That has a broken tar?) Do you want build-time requirements installed or not? Do you care if these option gets taken away? Someone might, so options keep getting added and never removed.
Every option is an attempt to satisfy feature requests or fix portability issues for someone over the last 14 years or so. Was that good a good decision in hindsight? Maybe. Is it a good decision for the future? Maybe not.
cpanminus is a fresh start, written for users who will trade off features for simplicity, but it has gone through tremendous feature bloat in merely months of development. I applaud miyagawa for drawing a line at 1.0 and leaving something simple behind.
But if history is any guide, the desire for TIMTOWTDI will come back to haunt us. There used to be one CPAN client and while it might have been a pain to configure, it pretty much just worked once that was done. Now I predict that within a few years, there will be dozens of CPAN clients and then we'll be hearing that newbies are complaining that they don't know which one to choose.
-- dagolden
I agree with Mr. Golden. There needs to be "one" and only "one" way to do it in the case of CPAN. If a new one is in the works ALL interested parties should be working on it.
Miyagawa: well, I basically set HTTP_PROXY and the regular CPAN client worked while cpanm didn't work. I just assumed it was something unsupported by cpanm. I can perform additional tests on Monday.
Nilson: cpanm calls env_proxy on LWP::UserAgent so it should work. Happy to take patches if that's not the case.
I just tested it again and it works fine. I guess I probably made an unrelated mistake when I first tested it and assumed it was cpanm's fault.
The last time I had to install a Ruby module, it was just like cranking a car manually to start it, except that I also had to make the crank handle myself, starting with raw unprocessed ore and no instruction manual. Thankfully, I've forgotten the details. As for python - well, I'll take perl's "cranky but stuff works once installed" over python's "hahaha, you expect to use this?" approach any day.
Yes, all the questions CPAN.pm asks suck, and some of the defaults are a bit dumb - defaulting to asking whether to follow pre-reqs is a classic. However, recent versions (including the one that comes with 5.12) will ask if you just want to go with the defaults for almost everything. Even so, I'm surprised that people like Debian and Redhat don't provide a pre-configured CPAN::Config with sensible defaults, including pointing at a debian/redhat/whatever CPAN mirror.
http://mikewatkins.ca/2010/05/15/easy-install-often-isnt/