[Python-Dev] PEP 376 proposed changes for basic plugins support
Michael Foord
fuzzyman at voidspace.org.uk
Mon Aug 2 01:56:19 CEST 2010
On 02/08/2010 00:46, Tarek Ziadé wrote:
> [snip...]
>> 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...
Michael
> Tarek
>
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
More information about the Python-Dev
mailing list