FWIW I usually prefer to run unittests against (PYTHONPATH) installed (debian/tmp/... if with extensions to be moved into -lib, or debian/python-X/... for pure Python module) version to make sure that everything got installed correctly. Also, if not too lengthy, I run unittests against all supported Python versions.
Altogether, it does make things a bit more "cumbersome" but more reliable. Examples: http://git.debian.org/?p=pkg-exppsy/brian.git;a=blob;hb=HEAD;f=debian/rules https://github.com/neurodebian/dipy/blob/HEAD/debian/rules on a related note, more I hit it: - I set $HOME to point to build/, and at times MPLCONFIGDIR=$(HOME) where I echo "backend : Agg" >| $(MPLCONFIGDIR)/matplotlibrc to assure consistent matplotlib backend if graphics are built during documentation generation And indeed, written recommendations would be nice ;) On Tue, 22 Feb 2011, Andrey Rahmatullin wrote: > Hello. > Many Python modules ship unit tests which do not require module > instalation or user interaction and so can be run automatically during the > build time. They can be a very good QA tool, but it looks like they are > not used in all packages. > python-pylons: not used > python-pybabel: not used > pylint: used, but produce errors which are ignored > python-sphinx: apparently used > In many cases $PYTHON setup.py test (for all supported $PYTHON's) is > enough to run the tests and any errors mean that something is wrong with > the environment (provided the tests are correct). > Shouldn't we have some written recommendations (or even policy) on this > matter? -- =------------------------------------------------------------------= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20110222135743.gx21...@onerussian.com
