Stories
Slash Boxes
Comments

NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

use Perl Log In

[ Create a new account ]

Alias (5735)

Alias
(email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Sunday September 05, 2010

09:26 PM

Should Module::Install move to explicit plugin declaration?

[ #40523 ]

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?

List all Journal entries

Should Module::Install move to explicit plugin declaration? More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

Yes, please (Score:2)

by autarch (914)

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: (Score:1)
  
  by frew (9054)
  
  I agree in full. It's like, "Here, let's declare our deps in this file, except for the secret ones that we assume!"
  
  --
  --fREW
  http://blog.afoolishmanifesto.com
Yes, something like this (Score:1)

by jjn1056 (1241)

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 u

--
Waiting on the Road to Eventually, I lost my Place On Line
I think so (Score:1)

by dwc (9785)

If only because it would make stuff like this [github.com] unnecessary.
Please do! (Score:1)

by sartak (7900)

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" :) (Score:1)

by DiamondInTheRough (4076)

Yes, agreed...
And a command-line option that lists the plugins for installing via cpanm would be great, too!

--
The new Strawberry Perl for Windows has been released! Check http://strawberryperl.com for it.