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