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.
_______________________________________________
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
