[TIP] Coming changes to unittest2 plugins

Tarek Ziadé ziade.tarek at gmail.com
Mon Sep 27 09:30:28 PDT 2010

On Mon, Sep 27, 2010 at 5:36 PM, holger krekel <holger at merlinux.eu> 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:
>> > package.module:Class
> The advantage of this notation is that it's explicit and clear what
> is the module part and what is the object ...

>> see distutils2.util.resolve_name()
> whereas this helper requires to import the actual package.

Yes because the intent there was to load the location. You could
create the same kind of helper without loading the code actually, if
you just want to locate the module, as long as the packages that
contains them are defined in setup.py or setup.cfg. Granted, it
requires more work to find them.

> 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?

Its harder but feasible.

Being able to convert easily the old notation to the new one is
important. Although I don't think the new notation should be created
with the pre-request that it will be easy to revert it to the old
notation. This is less important than having a notation that is clear
and simple imho.

> best,
> holger

Tarek Ziadé | http://ziade.org

More information about the testing-in-python mailing list