Fun with App::Prove::Plugin
Steve Purkis
steve at purkis.ca
Sat Feb 7 22:41:28 GMT 2009
On 5 Feb 2009, at 10:58, Andy Armstrong wrote:
[snip!]
> On 4 Feb 2009, at 21:29, Steve Purkis wrote:
>>
>> prove --foo
>>
>> loads the module App::Prove::Plugin::Foo if it exists. If it
>> doesn't,
>> it tells the user:
>
> Did you see the -P option? That's about one character away from what
> you're proposing :)
Yeah, but it doesn't look as nice:
prove --html
prove -PHTML
Ah well, I'm sure we'll all live ;-)
>> 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 :)
Agreed.
I've attached a patch for this (+tests+docs) - will commit when I can
remember my friggin password.
I ended up going with a separate Plugin->load() method, rather than
changing the args passed to Plugin->import() -- this affects modules
loaded with -M too, so I wanted it to be backwards compat. Hopefully
it all makes sense; if not lemme know (or fix it ;-).
It might make sense to split the plugin loading from the module
loading - as it stands, if any module loaded has a load() method,
it'll get called. If you guys think that's enough of a problem we
should change it.
It might also make sense to load the plugins before checking help/man/
version/dry (so the plugins could set any of these if need be). And
it might make sense to keep track of the actual plugin classes
loaded. But I'm outta time...
hth,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugins.patch
Type: application/octet-stream
Size: 6990 bytes
Desc: not available
Url : http://www.hexten.net/pipermail/tapx-dev/attachments/20090207/f2e0307a/attachment.obj
-------------- next part --------------
More information about the tapx-dev
mailing list