My problem with having unit tests included in a binary distribution is
that they take up space and have no way to be run, so can certainly be
called a waste of space. OK, may be they could be run by a user
importing the correct modules, etc, I meant no simple way (eg. as done
in a source package with the command
$ setup.py test
). Also anyway what would the reason be for a user to run tests on the
binary module, I (or another developer in the cases of modified
versions) should have run the tests before distributing the binary
package. Source distributions are a different matter in my mind, someone
can modify it and so having tests is useful.
OK, to possible solutions:
1. Distribute offers the keyword argument "convert_2to3_doctests", may
be it could have one to give test directory, and then .py files in that
could be converted.
2. As setuptools automatically includes test/test*.py, why can't
distribute actually compile these files as well (I question whether
tests in a test directory should be prefixed with test, but I don't have
a really strong view should people disagree).
May be even both of those could be combined, so if a test directory is
not specified then test/test*.py is the default (if such a directory
exists).
As a note: my views of structuring a source distribution and not
including tests in binary distributions may be influenced by my java
programming, hope that helps explain where I may be coming from.
Michael Whapples
On 11/10/09 21:43, Lennart Regebro wrote:
2009/10/11 Michael Whapples<mwhapp...@aim.com>:
Hello,
Firstly thanks to those working on distribute, I had been using setuptools
but was getting annoyed with it slowly developing (eg. not having python3
support, etc), so distribute seems like it is what I am looking for.
Any way I am using distribute for one of my packages now (I wanted to try
and support python3) but have noticed something which doesn't work for me. I
have my main package sources in one directory and then tests in another
directory (it makes it easy to separate them out when creating a binary
package). Now this works fine for python2.x as I can include the tests in a
source distribution by using MANIFEST.in, but it doesn't work for python3 as
distribute doesn't seem to run 2to3 on them (although they are run by the
distribute/setuptools test command in the setup.py script).
You have to tell setup that these files are source files, somehow. By
just including them in MANIFEST.in but not in any source package
they'll get treated as resources. Perhaps if you included it as a
apckage or py_module?
It is true that Distribute picks up files in test/test*.py for
inclusion in source distributions, which I didn't know until now.
These will not be included in the binary distribution, and hence not
converted with 2to3 either, so that will not work with 2to3 support.
That needs to be documented or fixed somehow, although I don't really
know how...
If I were to
structure my source distribution like the distribute example then how do I
ensure unit tests aren't included in a binary distribution?
Well... what is the actual use case for doing that? There's no problem
with distributing the tests (in fact, I would say it's a good idea).
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
