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

Michael Foord fuzzyman at voidspace.org.uk
Fri Jul 30 23:02:44 CEST 2010


On 30/07/2010 21:56, P.J. Eby wrote:
> At 03:34 PM 7/30/2010 +0100, Michael Foord wrote:
>> Automatic discoverability, a-la setuptools entry points, is not 
>> without its problems though. Tarek outlines some of these in a more 
>> recent blog post:
>
> FWIW, it's not discovery that's the problem, but configuring *which* 
> plugins you wish to have active. Entry points support access by name, 
> and it's up to the application using them to decide *which* ones to load.
>
> The underlying idea is that entry points expose a hook; it's up to the 
> app to decide which ones it should actually import and use. An 
> application also can list the available plugins and ask the user, etc. 
> (For example, setuptools only loads "setup() argument" entry points 
> for specified arguments, and command entry points only for the 
> commands a user explicitly invokes.)
>
> IOW, entry points provide access to plugins, not policy or 
> configuration for *which* plugins you wish to use. This was an 
> intentional decision since applications vary widely in what sort of 
> configuration mechanism they use. In the simplest cases (e.g. 
> single-app environments like Chandler), simply making the plugin 
> available on sys.path (e.g. via a special plugins directory) is 
> configuration enough. In more complex use cases, an app might have to 
> import plugins in order to get more information about them.
>

Right (and thanks), and in the unittest plugin system the user decides 
which plugins should be active by listing them explicitly in the 
configuration file.

Discovery could be useful for a tool that tells the user which plugins 
are available and modify the config file *for them* to switch plugins on 
and off. Useful metadata would then be which config options a plugin 
supports (and their defaults) so they can be added to the config file 
too when a plugin is activated.

Michael

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