The power of not being all things to all people

The Perl community seems abuzz about the cool new cpanminus client by Tatsuhiko Miyagawa. After about two weeks of development, this is a reasonably functional CPAN client with just a fraction of the overhead, complexity and verbosity of the CPAN and CPANPLUS clients that come with the Perl core.

It's a remarkable achievement, not only technically, but in the reaction it has sparked. As one of the (sometimes reluctant) maintainers of CPAN and CPANPLUS, I've realized that I both love and hate cpanminus.

  • I love that Miyagawa has done so much with so little and in such a short span of time
  • I hate that fanboy-types flocked to it and trashed the older clients without noting cpanminus' limitations
  • I love that Perl toolchain maintainers have rallied around Miyagawa and contributed their wisdom to make cpanminus better instead of rejecting it
  • I hate that one of Perl's great strengths (CPAN) has legacy clients that are so unwieldy, hated and difficult to maintain

Miyagawa graciously acknowledges standing on the shoulders of giants. Still, I can't shake the nagging thought that cpanminus should never have been necessary in the first place.

What I've come to realize is that cpanminus is another example of the power of not being all things to all people. Miyagawa doesn't promise that it works for all of CPAN or that it works everywhere that Perl does. He doesn't have to. Making it work for 99% of CPAN for 99% of people is more than good enough.

I've been co-maintaining various parts of the Perl toolchain for a while now. It's a frustrating challenge needing to make thing work everywhere, for everything, and trying as hard as possible not to break backwards compatibility. Plus, I don't even get to use CPAN to make life easier. I don't get to use handy tools like Moose or DateTime or Regexp::Common or SQLite or anything in the Config::* namespace or even basic tools like Archive::Zip. Nearly everything is done by hand.

Things have to work with just core Perl on a diverse set of platforms and with an incredibly limited set of assumptions. For example, the Perl core still doesn't come with an HTTP client, so CPAN has to rely on FTP or command line programs to bootstrap LWP. (This is something I personally plan to tackle during the Perl 5.13 development series later this year.)

I think this is an ongoing challenge for core Perl development in general. It's a lot of work to be all things to all people and I keep wondering whether making things simpler and better for 99% of people would be a better choice. (Anyone else for use strict by default? I hope that finally comes to pass in Perl 5.14.) chromatic writes about this topic often in his Modern Perl blog and I usually tend to agree with the points he makes. (October February 2009 had a particularly good series of posts.)

In the meantime, I look at cpanminus with greed and envy. Miyagawa++

This entry was posted in cpan, perl programming, toolchain and tagged , . Bookmark the permalink. Both comments and trackbacks are currently closed.

8 Comments

  1. Posted March 2, 2010 at 4:49 pm | Permalink

    Thanks for the kind words!

    Yes, it's so great that every day i learn new things on #toolchain to make the thing work (or learn about some historical corner cases that could have made CPAN/PLUS so complicated, which I take the freedom to ignore :)). And i share your hatred/concern about the fanboy type of people who trashes the older clients without being aware of their historical efforts and that cpanminus owes them for everything, and also owes people running good mirrors (like you) and search.cpan.org sites.

    I'm thrilled to continue my work to make cpanm play even betterl with the rest of CPAN ecosystem such as CT 2.0.

    xdg++

  2. Posted March 3, 2010 at 12:29 am | Permalink

    David,
    It's frustrating to see that you wrote the exact post I would have written (minus the bit about being a CPAN.pm maintainer) if I had managed to get my behind off the ground. So as usual, all that I can do is throw in a resounding "I couldn't agree more to this"!

    Well, on second thought. No frustration involved :) Thanks for writing up your thoughts on the matter. They're spot-on.
    Steffen

  3. brian d foy
    Posted March 3, 2010 at 12:42 am | Permalink

    Indeed, my second try at cpanminus was to use it with a MiniCPAN, which brings people back to the configuration issue, which isn't the point. :)

    Now we need a Consumer Reports style chart that shows people which client they should use. I figure most people will be content with cpanminus (espescially when it can auto-discover mirrors, etc), but some people will need some extra features and will have to get the more flexible tools.

    I've already added many features to App::Cpan that can handle the "zero conf" stuff. The -j switch lets people use any configuration file they like, so I can imagine that we can distribute config files for different sorts of users. The trick is to make the right one the default. Setting "trust CPAN testers" will get rid of a lot of most of CPAN.pm's output.

    And, you and I have already talked about giving the CPAN.pm internals a thorough scrubbing for its output interface. :)

    • Posted March 3, 2010 at 12:38 pm | Permalink

      brian, i have a minicpan plugin in the git master which works with the local minicpan mirror when the internet connection is offline. It's even configuration-less if you have ~/.minicpanrc (which minicpan web server requires you to set up). I'm talking to rjbs and acme about making it a standard -- All of cpanm plugins can hopefully follow the same pattern: if you need some configuration, you should do that outside and cpanm will pick the sanest default.

      I'm also excited to work with you on DarkPAN index support -- once I implement the "proper mirror" support I think it's only about configuring which mirror to use for which namespace etc. and it should be straightforward.

  4. PB
    Posted March 3, 2010 at 10:33 am | Permalink

    You link text says "October 2009" but you actually link to chromatic's February, 2009 archives.

    • dagolden
      Posted March 3, 2010 at 11:00 am | Permalink

      Good catch. Fixed!

  5. Chris
    Posted March 3, 2010 at 11:30 am | Permalink

    So in a post about not being all things to all people, you describe your plans to put an HTTP client into Perl core :) Gotta love the modern age.

    --Chris

    • dagolden
      Posted March 3, 2010 at 11:36 am | Permalink

      Yeah, ironic isn't it? Well, I'm not suggesting putting an XML parser in core, at least.

One Trackback

  • By Perl Ain’t Dead… on March 3, 2010 at 11:21 am

    [...] Not only are there all these new HTTP based projects there’s a new cpan module installer – cpanminus – which has had some rave reviews. [...]

© 2009-2014 David Golden All Rights Reserved