Module::Install has been through a long period of gradual stability over the last year, without any really dramatic improvements to the grammar or APIs.
With the more urgent "it doesn't work with blah" stuff mostly solved now, one of the big remaining issues is around error clarity and excessive magic.
For example, some random author that is trying to checkout a Catalyst project needs:
1. To have Module::Install installed.
2. To have Module::Install::Catalyst installed.
In the case of the former, you get the semi-cryptic but at least standard "Can't find inc/Module/Install.pm in @INC" message, so the error is resolvable.
But in the latter case, you're likely to get something like "Unknown command 'catalyst_ignore'", with no real obvious resolution mechanism.
I think this idea of automatic plugin discovery is starting to hit it's limits in terms of clarity.
And so I'd like to do something counter to my natural instincts here, and make M:I more verbose.
I'm thinking of something like the following for explicitly declaring the use of a non-core Module::Install extension.
use inc::Module::Install qw{ Catalyst XSUtil };
This would both allow M:I to error with a much more meaningful error when you don't have a plugin, and also prevent the loading of unused plugins which should prevent accidental plugin collisions (some of which I've seen occurring in the CPAN Testers machines).
Thoughts?
Yes, please
autarch on 2010-09-06T02:50:30
I'm not a big fan of MI, and I think the main reason is it's too freaking magical. This "feature" is a perfect example of magic gone bad. It adds a _tiny_ bit of convenience (arguably less than tiny) while adding significant headaches for those who don't understand WTF is going on.
Re:Yes, please
frew on 2010-09-06T02:54:08
I agree in full. It's like, "Here, let's declare our deps in this file, except for the secret ones that we assume!"
Yes, something like this
jjn1056 on 2010-09-06T14:24:22
I personally have been annoyed when I go to work on a project and when I try to run the Makefile.PL for the purposed of getting dependencies installed (either via "make installdeps" or cpanm --installdeps
.) I get a list of 'pre dependencies', mostly stuff to get Module::Install bootstrapped. I know there's 'config_requires' but this doesn't seem to help with the problem. Typically I solve it with a hack, when I create a new local::lib for a project I preload most of the common Module::Install plugins I use (via Task::BeLike::JJNAPIORK) and just tell contributors to preload that module before doing "perl Makefile.PL", but that feels too much like a hack, although its only a single extra step.
It would be really nice if I could do something like "perl Makefile.PL --list_plugins | cpanm" or even "perl Makefile.PL --bootstrap_author_modules" or similar.
On the other hand, perhaps moving toward using Fatpacker, where the Makefile.PL get generated via an authorside build script, similarly to the way App::cpanminus works, might be a more simply solution (athough that would probably get ugly with plugins like Module::Install::Catalyst, since that's part of the Catalyst::Devel package, which depends on Catalyst, and you'd end up Fatpacking a ton of stuff... Maybe Module::Install::Catalyst could be busted out of Catalyst::Devel?)
I'm not sure which is the best option, but I do know it would be awesome if I could tell someone all they need to do to get started is clone my repo and do "cpanm --installdeps
." or similar and it just works without having to do some preparation.
I think so
dwc on 2010-09-06T14:57:52
If only because it would make
stuff like this unnecessary.
Please do!
sartak on 2010-09-06T19:49:20
I really dislike this particular MI magic. Even for experts it can be a pain to guess what the right Module::Install plugin to install.
"excessive magic" :)
Yes, agreed...
And a command-line option that lists the plugins for installing via cpanm would be great, too!
