Fun with App::Prove::Plugin

[Andy Armstrong]

On 4 Feb 2009, at 21:29, Steve Purkis wrote:
>> On machine A I discover that prove supports the --foo option - so I
>> got to machine B and try the same thing - but --foo is rejected. So I
>> update App::Prove since I obviously have an out of date version - but
>> --foo still doesn't work. What do I do next?
>
> Pull your hair out?
>
> Or: (and this is somewhat crack-fueled) make the option being parsed
> equal to the plugin name.  That way There Can Be Only One.  eg:
>
> 	prove --foo
>
> loads the module App::Prove::Plugin::Foo if it exists.  If it doesn't,
> it tells the user:
>
> 	"Sorry, I don't know how to --foo.  Maybe you're missing the 'Foo'
> plugin?"

Did you see the -P option? That's about one character away from what  
you're proposing :)

> (If you wanted to be real clever, you could even offer to install it
> for them via CPAN.)
>
> Then we could use some of Eric's ideas (ala Getopt::AsDocumented -
> which is a really good idea, btw) to load params the plugin can
> handle.  "Loadable modes" as Eric says.
>
>
>> Perl's -M/m/d switch is a good interface from that point of view -
>> because it makes it explicit that you're loading a module.
>
> Yeah, I know what you mean.
>
> All this talk of auto-loading plugins based on cmdline params is
> interesting & potentially useful, but it's a nice-to-have from my
> POV.  What would be definitely useful is letting the plugins modify
> the App::Prove object.  Any thoughts on that?


Yeah, I like that - in fact we really do need that.

My preference would be to mate that with the existing -P switch but  
I'm flexible :)

-- 
Andy Armstrong, Hexten