On Fri, Dec 17, 2010 at 05:26:47PM -0500, Barry Warsaw wrote: > Something bugs me about virtualenv, distribute, development, and testing. I > figure I'm probably doing something wrong and that y'all will be able to set > me straight.
I've a set of rules that serve me well. Rule #1: $VCS checkout and 'make test' should run the tests. This means I've a Makefile that creates the virtualenv/bootstraps a buildout, with all my test dependencies, and then runs the actual test runner script (which may be setup.py test, or it may be something different). (Likewise, 'make run' should start a local copy of the application, if this is a runnable application. But that's unrelated to testing.) <snip> > Or do you think that 'python setup.py test' should use the in-place tree and > this is Just A Bug? I don't know if it's a bug or not. I always assumed it worked as designed: perhaps trying to verify that your setuptools metadata is correctly specified and no modules are going to be missing when the package is installed? Actually, isn't running the tests from the build/ directory required when you want to support both Python 2.x and 3.x via 2to3, and you want to run the tests with Python 3? (I haven't done that personally, but I think Distribute explicitly supports this.) FWIW I found this tests-against-build-dir behaviour mildly irritating, but mostly irrelevant: I always specify my own test suite loader in setup.py (for various reasons, e.g. doctests), and my test loader ignores build/ and uses the in-place tree. I tend to support 'python setup.py test' as a convenience for other people. I dislike the copious build output it always produces at the beginning, and the time wasted to do the build. This might change when I start paying more attention to Python 3. -- Bumper sticker: No radio - Already stolen.
signature.asc
Description: Digital signature
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
