[Python-Dev] PEP 376 proposed changes for basic plugins support

Michael Foord fuzzyman at voidspace.org.uk
Mon Aug 2 01:56:19 CEST 2010


On 02/08/2010 00:46, Tarek Ziadé wrote:
> [snip...]
>> I don't think that unittest would use a distutils2 (or pkgutil) supplied API
>> for activation.
>>      
> But the discovery API you will use might just simply filter out
> disabled plugins.
>    

I did consider asking this but thought it was a silly question - there 
*must* be an API to get all plugins otherwise applications couldn't 
activate or deactivate them (or allow their users to do this) - and then 
how could users activate a non-active plugin? (I guess there could be 
private APIs that only distutils2 is supposed to use, or the script that 
you mentioned.)

On the other hand if the user has deactivated a plugin through 
distutils2 I have no problem with it not being available to unittest.

> In any case, if unittest2 tries to bypass this activation flag I don't
> see the point of having it there
> since its purpose is to let the end-user deactivate a plugin that
> might be used by several applications.
>
>    

Right. As I explained, I don't think unittest *can* use this mechanism 
since it can have plugins active for one project but not for another. I 
would really have no problem with this machinery existing, but it 
wouldn't be useful/usable by unittest for plugins.

It sounds like it can fairly easily be bolted on as a new feature set 
later *anyway*, so dropping it for now simplifies the initial 
implementation.

Wouldn't that mean that distutils2 would still need its *own* system for 
telling whether or not installed plugins are active? So maybe you have 
to build it anyway.

>> unittest needs *separate* per user and per project
>> activation (a plugin active for a project may not be needed in other
>> projects and so won't be enabled at the user level for example).
>>      
> And sharing plugins across apps is a use case too: Nose could use
> unittest2 plugins and vice-versa.
>    

Hehe, well - that's a different story...

Michael

> Tarek
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.




More information about the Python-Dev mailing list