On 02/08/2010 01:03, Tarek Ziadé wrote:
On Mon, Aug 2, 2010 at 1:56 AM, Michael Foordfuzzyman@voidspace.org.uk 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
I agree it sounds like an important feature - a point of control for the user or the system as you said on irc. I still don't think unittest *can* use it, but I'm quite happy with the fact that if a user deactivates a plugin through distutils2 then it is no longer *available* to unittest.