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

[Tarek Ziadé]

On Mon, Aug 2, 2010 at 1:11 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> This seems fine; I mean it isn't written directly by humans or intended to
> be read directly by humans I guess. :-)
>
> (Users will specify plugins in the setup metadata and this will be written
> on install by distutils2 - right?.)

Yes, exactly

>
>> = per-user plugins =
>>
>> A plugin can be activated or disable globally, but a user should be
>> able to configure them differently.
>>
>> A ini-like plugins.cfg file is added per-user (its location to be
>> defined -- its discussed in another thread) and
>> overrides the state of the installed plugin. It provides a value for
>> each app.type.name plugin.
>>
>>   [plugins]
>>   unittest2.plugin.pep8 = 0
>>   distutils2.commands.funkycommand = 0
>>
>> Notice that the user can have plugins provided by distributions
>> installed in his own per-user site packages.
>>
>>
>
> 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.

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.


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

Tarek