On Wed, Oct 01, 2014 at 11:23 +0200, Peter Odding wrote:
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
procedures.
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.
The problem with wheels is that there is no way to "devpi test" them because currently the command's implementation assumes that a package contains a tox.ini and the tests. Even if a wheel could contain inlined tests there'd still not be no tox.ini. What we need is a canonical way to discover a tox.ini and the tests from a wheel. Using the "sdist" for that seems like a straight forward choice.
Are you actually using "devpi test" or "tox", btw?
holger