[TIP] Coming changes to unittest2 plugins
michael at voidspace.org.uk
Mon Sep 27 08:38:09 PDT 2010
On 27/09/2010 16:36, holger krekel wrote:
> Hi Tarek, Michael,
> On Mon, Sep 27, 2010 at 16:47 +0200, Tarek Ziadé wrote:
>> On Mon, Sep 27, 2010 at 4:33 PM, Michael Foord<michael at voidspace.org.uk> wrote:
> The advantage of this notation is that it's explicit and clear what
> is the module part and what is the object ...
Isn't the last part always the object? Or am I missing something...
>>> 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()
> whereas this helper requires to import the actual package.
> I'd rather like to be able to derive as much information from
> the static distutils2 metadata as possible. Concretely, using
> "a.b.c" notation for entry points would make it harder to write
> a tool that takes setup.cfg and generates a setuptools-compliant
> setup.py. Or am i missing something?
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 testing-in-python