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.)
On the other hand if the user has deactivated a plugin through distutils2 I have no problem with it not being available to unittest.
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.
Right. As I explained, I don't think unittest *can* use this mechanism since it can have plugins active for one project but not for another. I would really have no problem with this machinery existing, but it wouldn't be useful/usable by unittest for plugins.
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.
Wouldn't that mean that distutils2 would still need its *own* system for telling whether or not installed plugins are active? So maybe you have to build it anyway.
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.
Hehe, well - that's a different story...