On 2 Aug, 2010, at 2:03, Tarek Ziadé wrote:
On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord email@example.com wrote:
On 02/08/2010 00:46, Tarek Ziadé wrote:
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.
I did consider asking this but thought it was a silly question - there *must* be an API to get all plugins otherwise applications couldn't activate or deactivate them (or allow their users to do this) - and then how could users activate a non-active plugin? (I guess there could be private APIs that only distutils2 is supposed to use, or the script that you mentioned.)
yes, there will be a way to retrieve them all
It sounds like it can fairly easily be bolted on as a new feature set later *anyway*, so dropping it for now simplifies the initial implementation.
but then we would be back to the problem mentioned about entry points: installing projects can implicitly add a plugin and activate it, and break existing applications that iterate over entry points without further configuration. So being able to disable plugins from the beginning seems important to me
It should be the role of the application to manage which plugins are enabled and not the library. The library can provide an API that applications can use to manage which plugins are activated, but the library should IMHO not force a specific scheme onto the application.
Keeping management outside of the libraries allows applications to provide their own mechanisms for it, such as the unittest2 configuration or even a configuration screen in a GUI application. The latter is what's the most interesting to me, have a GUI application where users can optionally add functionality by adding a egg-file[*] to a plugin directory. It would be nice if I could use the stdlib plugin API for that instead having to use my own inventions.
BTW. The spec seems to assume that the PLUGINS file is writeable, that needn't be true for example when packages are installed by a system tool or on multi-user systems where only sysadmins can install packages in a central site-packages location.
[*] that is, a zipfile containing an installed distutils distribution