[TIP] Coming changes to unittest2 plugins

Tarek Ziadé ziade.tarek at gmail.com
Mon Sep 27 07:47:54 PDT 2010


On Mon, Sep 27, 2010 at 4:33 PM, Michael Foord <michael at voidspace.org.uk> wrote:
>  Hello all,
>
> After recent conversations with Holger Krekel and Robert Collins I have
> decided to make a fairly major internal changes to unittest2 plugins. I'm
> getting rid of all global state, which includes the global hooks that are
> currently the core of the extension machinery.
>
> Getting rid of global state always *sounds goood*, but it isn't without API
> consequences. With no global access to the hooks set it needs to be passed
> down and 'made available' to the runner, loader, suites and all test cases.
> This is annoying, but probably still better than global state. Removing the
> global state makes *testing* the plugin machinery massively easier
> however... It also allows multiple different plugin configurations within
> the same process (which is nice but only actually useful for a small set of
> use cases).
>
> This refactoring also means changing the way plugins are initialized, merely
> importing the plugin is no longer enough (the metaclass goes - which makes
> me sad but is probably also a good thing). I expect to change configuration
> to look like:
>
> package.module:Class
>
> I hate the colon but it is how entry points do it *anyway*. Function based
> plugins will still be possible, but will *require* an initialization
> function that takes the hook set.

Minor nitpick: I don't think you need a colon here. After some
discussion we are dropping it in distutils2 in all places where we
point code, since it's easy to find which part is the module and which
part is not when configuring a code location.

see distutils2.util.resolve_name()

A "location.replace(':', '.')" is a simple way to make it
setuptools-compatible is this is whised.

Regards
Tarek

-- 
Tarek Ziadé | http://ziade.org



More information about the testing-in-python mailing list