On Mon, Aug 2, 2010 at 1:11 AM, Michael Foord
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