[Python-Dev] proto-pep: plugin proposal (for unittest)

Michael Foord fuzzyman at voidspace.org.uk
Fri Jul 30 17:01:01 CEST 2010


On 30/07/2010 15:37, Tarek Ziadé wrote:
> On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw<barry at python.org>  wrote:
> ..
>    
>> * Registration - How do third party plugins declare themselves to exist, and
>>   be enabled?  Part of this seems to me to include interface declarations
>>   too.  Is installation of the plugin enough to register it?  How do end users
>>   enable and disable plugins that me be registered on their system?  How do
>>   plugins describe themselves (provide short and log descriptions, declare
>>   options, hook into command line interfaces, etc.)?
>>
>> * Installation - How are plugins installed on the system?  Do they have to
>>   appear in a special directory on the file system?  Do they need special
>>   setup.py magic to write extra files?  Do they need to live in a pre-defined
>>   namespace?
>>      
> FWIW We are thinking about adding in distutils2 a system quite similar
> to the entry points
> setuptools has, but with extra abilities for the end user :
>
> - activate / deactivate plugins without having to remove the project
> that added them
> - configure globally if plugins are implicitely activated or not --
> and maybe allow the distutils2 installer to ask the user
>    when a plugin is detected if he wants it activate or not
> - provide a tool to browse them
>
> This will be done through files added in the dist-info/ dirs, with the
> new PEP 376 api we are
> adding to pkgutil
>
> The idea is that the end user should be able to have a full control on
> what's activated in his system,
> without relying on the developer choices
>    

This system sounds great. unittest could certainly use it for 
discovering plugins provided by other packages.

The question then is still how to decide which ones should be active for 
any individual project (just because a plugin is available doesn't mean 
you want it used for every project). A configuration system is still 
good for this, but that kind of negates the advantage of discovery if 
the user still has to configure the plugin *anyway*.

For framework authors not using the default test runner ("python -m 
unittest" or "unit2") this would be very useful.

Michael

> Cheers
> 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