On Sat, Jul 2, 2011 at 2:07 AM, Barry Warsaw <ba...@python.org> wrote: >>In some sub-communities, py.test or nosetests are the standard, not >>setup.py test. > > Yes, but if I understand where Michael is taking unittest2, those can just be > refactored to be plugins instead of separate standards. Then `python setup.py > test` can be the preferred and documented standards, while allowing those > other command lines to also exist.
unittest2 is still a unittest runner at heart; the basic model is sound to scale up to N processes and so forth (see tox or testrespository for instance), but compatibility with arbitrary ways of running is pretty tricky. See for instance the guts of the following three runners: trial, django and zc.testing.testrunner. All I'm saying is don't hold your breath: those communities could have plugged into the original unittest compatibly but didn't - I think it needs to be massively more clear *how* to do so, and on older Pythons for those communities - they don't live on the edge ;) - for one-runner-with-plugins to reach that point. As a data point, in the java world multiple runners is still the case, with some common interop on output format. -Rob -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ3HoZ1mOqYGcMfn0Lf514dBmmuBOD5GL78=mvfrewqxvsc...@mail.gmail.com
