On Mon, Aug 2, 2010 at 1:11 AM, Michael Foord <fuzzy...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
