I always bundle my tests inside my Python packages so that they are
published to PyPI (and as such they would also be included in wheels if I was publishing those) however I seem to be in the tiny minority in the larger Python community on this point :-)
Not sure it's a minority. I used to inline tests as well but for various reasons now put them outside. With wheels you won't be able to inline at least a tox.ini easily anymore.
Fair enough, maybe my impression is just wrong, or it could be that the general attitude about this point is changing.
Also, running tests against an installed sdist seems like added value to
me, because lots of people get setup.py files wrong on the first few iterations, and this would point out bugs in their installation
On the other hand you could be opening a can of worms, so maybe make this an optional thing? :-)
To get an "optional can of worms"? :)
That's a good point, an optional can of worms is still a can of worms :-). I was more thinking along the lines of giving people the option to test one way or the other, so that they can opt in to or opt out from testing installed sdists because they know whether this kind of testing will work for their project, given the way they've set up their testing infrastructure.
On 29 September 2014 12:41, holger krekel hol...@merlinux.eu wrote:
Currently you can't use "devpi test" with wheel files because they don't contain the tests unless you put all tests inside the software archive. To get the tests we could require that there is an "sdist" archive file containing the "tox.ini" file and the tests. Thus "devpi test X" would potentially download two files, a platform specific one and the sdist to configure and perform testing.
Apart from running the tests against the sdist we probably also want to run the tests against the installed sdist. Not sure i grasp all implications yet (also UI wise) but does anyone of you have preliminary thoughts on the issue?