Phillip J. Eby wrote: > At 05:36 PM 1/5/2007 +0200, David Fraser wrote: >> How would this work if for example, you're using an alternative testing >> framework (like py.test) for your test? > If I understand correctly, py.test simply won't be usable for this > scenario, because it assumes tests are files first and modules second, > if at all. It's not equipped to discover tests that are inside eggs, > which is the whole point of this proposal. > Integrating py.test with the "setup.py test" command, on the other > hand is possible and relatively simple; just create a > unittest-compatible test suite object that wraps py.test, and a test > loader class that grabs the necessary arguments from the test_suite > argument string. No modifications to setuptools are required, you > just provide appropriate values for the test_suite and test_loader > arguments to setup(). > > But the proposal being discussed is for tests that are actually > *installed* somewhere, and thus might be in a zipfile. So I need to go and code a test enumerator for py.test to discover tests within eggs (which is possible) >> Great, so at least the testing framework could be declared as a >> dependency > For "setup.py test", this is already possible via the 'tests_require' > argument to setup(). What's being discussed here is a standard for > *installed* tests -- that is, tests that a developer has chosen to > make part of their projects's installed code. The existing "setup.py > test" subsystem requires a *source* distribution, not installed code. OK great, thanks for clarifying...
David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig