[TIP] unittest2 and the future of nose

C. Titus Brown ctb at msu.edu
Thu Mar 4 14:19:47 PST 2010

On Thu, Mar 04, 2010 at 04:13:31PM -0500, Olemis Lang wrote:
> [...]
> >
> > Third fact: setuptools is dying, distribute is going with it, and
> > something called distutils2 is going to rise to take its place.
> The express intention of breaking setuptools (and the associated
> publicity ...), and especially the `test` command, is something I
> don't really like *AT ALL*, especially because it has supported Python
> extensions since so long ... I don't really think that phasing it out
> is the right way ?to save the world?
> Setuptools 0.7.x is under development right now and introduces new
> features ( especially for the `test` command )

Hi Olemis,

it's just simple dependency inversion.

distutils has horrible nasty parts to it, and I gather a lot of what setuptools
does is wrap or monkeypatch those to be less nasty and more extensible.
distribute fixed some outstanding bugs in setuptools, without fixing distutils;
the new distutils2 is going to make backwards incompatible changes to distutils
that have the effect of fixing it.

The dependency inversion is this: the stdlib and packaging cannot depend on
external packages, and we definitely *want* a lot of the functionality for
packaging built into Python (so that everyone's packages can take advantage
of it).  So we must somehow incorporate functionality from setuptools into
the stdlib.  There's no good way to do that in a backwards compatible way.

So "we" (the BDFL, and the people who actually write CPython and maintain
the stdlib - not me!) decided to include distutils2 in the stdlib going
forward, so as to make good packaging dependent only on the stdlib without
breaking everything that used (or monkey-patched) distutils.

I think there are a lot of choices for you and other individuals here on how to
proceed -- support setuptools? focus on distribute? etc. -- but I don't think
complaining about the situation is going to do any good.  It's a fact, at this
point.  Helping make the transition less painful by pointing out rough
corners, or working on packaging in general by e.g. hacking on setuptools to
provide cool *new* options for packaging, etc. is going to be much more

I'm also not sure why you think the 'test' command is going to be broken
or phased out, either, but that's a different question...

C. Titus Brown, ctb at msu.edu

More information about the testing-in-python mailing list