The future of cpanminus

I started developing cpanminus one night in February when i got stuck with running CPAN.pm on linode VPS, and you may have noticed from its name, it's rather some kind of toy/fun project that's not meant to be serious. I was even considering to put it under Acme:: namespace.

But in a few days, it turned out people got really excited and think it's really a great idea. That was my surprise as well as a pleasure. One week later I started implementing more features such as local::lib bootstrap and a plugin system, which is still a developer-only easter egg feature (you need to look at the source code how to enable that :)).

Simple and Hackable

I know a lot of people who have switched from CPAN.pm/CPANPLUS to cpanm just because cpanminus just does what they want. I also know a couple of hacker type of users who uses cpanm because they want to use its bleeding edge features such as showing changes automatically or to be growled when installation was successful.

I also know there's an use case to use cpanm as a bootstrapping tool, using curl -L http://cpanmin.us | perl - Module, or to use it as the default installation tool for Module::AutoInstall, Dist::Zilla or Acme::Everything.

So I guess there are two use cases, or major interests to cpanminus. One is that they want a CPAN client that is tiny, config-free, deps-free and just works with sane defaults for 99% of the users. The other is a CPAN client that is easy to understand, hackable and can be extended.

Conflicts

I think those two use cases will conflict eventually. Although the plugin system is written carefully, adding features like growl notification or cpanratings integration to a tool that is meant to "just work" is very weird. Features such as "checking out the code from github and build using dzil" shouldn't be used by 99% of the people. There've been criticisms on cpanratings as well as on IRC that cpanminus SLOC is now getting bigger than CPAN's CPAN::Dist which i think is fair.

Plans

So here's a quick strawman proposal.

1) I will fix the remaining tasks and wishlist for cpanminus such as "proper mirror configuration support" or "prompt when the installation fails", and drop cpanminus current plugin architecture and make it a 1.0 release, then freeze the features.

2) A separate tool that meets the purpose of "cpanm for hackers" will be created. Let's call it foo here because that obviously won't be the official name. foo will inherit the existing plugin features of cpanminus and actually uses cpanm (as a command line or with scripting API interface, not sure yet) when building things.

foo can be of course bootstrapped by cpanminus, but won't have the restrictions that cpanminus has -- you can use LWP or JSON, and can assume perl 5.8.1 etc. However it should still be kept as lightweight and has as minimal dependencies as possible. Features such as cpan-outdated or uninstalling modules would become a subcommand for foo. 

The biggest change i want to make for it actually is to make the subcommand system the default -- so it will be `foo install Plack` rather than `cpan Plack`. (and of course plugins can register its own sub commands).

I guess if there's a criticism against this plan, that'd be "So you're now REALLY reimplementing the rest of CPAN.pm/CPANPLUS. Why not contributing them back?", and i think it's a fair argument. But at the same time that's exactly the reason to separate out foo from cpanminus and keep it as simple as possible.

Let me know what your thoughts are -- i plan to work on these changes at the QA hackathon next weekend in Vienna. 

Comments

[zhang]

cpanm is great!

[john napiorkowski]

Well, I m using cpanminus now as a big part of my developer toolchain. Honestly I think the problem domain we as developers trying to deploy Perl apps has changed and perhaps cpanminus meets that new problem domain better. For example there was a time where everyone just wrote scripts, installed cpan modules to a global shared perl and deployment meant copying stuff to one or two production servers. Now we tend to use tools like local::lib to help isolate dependencies and allow developers to work more independently; this has change the deployment problem since generally now when I deploy a new version of code that will involve newer and more cpan modules. Used to be you'd send an admin a list of new cpan modules you needed and she'd install them on the production box and you'd be good to go. Now you are deploying to dozens or more servers and installing lots of cpan stuff all the time. Personally I find cpanminus is addressing that need better than the existing CPAN tools. I'm not intending to criticize, just the reality is the canonical tools are not a great fit (at least for me) for the problems I need to solve, and those tools can't change. So I guess I'm voting in support of what you propose. I'd like a minimal cpanm tool to bootstrap my setup and work with machines of questionable configuration. Personally I hope that tool will continue to support some very useful and common deployment strategies like using local::lib; if that was removed the tool would be a lot less useful to me.

I haven't played with plugins so much, haven't needed them, but I guess having a separate space would encourage us to keep cpanminus really focused on being great at what it currently does so I am in favor of that.

Thanks for kicking this off. Something like this has needed to happen I think for a while.

[miyagawa]

Yeah, totally agreed. And yes, the current feature such as local::lib integration and installing deps with --installdeps will stay at cpanminus because they *are* really useful to have :)