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.
Recent Comments