Hey Holger,

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.

Forgetting about wheels for just a moment, does this require people to include the tox.ini in their source distribution archives using MANIFEST.in? I guess so because I see that "devpi test" works (exclusively?) by downloading the sdist and testing based on the downloaded artifact. I see now why wheels are so different from source distributions in this context; wheels contain only what will be installed by users (basically a binary distribution instead of a source distribution) while source distributions can contain additional files like a readme and tox.ini file. Of course there are ways to include data files in binary distributions, but that could get nasty.

I guess given all of this, using the source distribution to discover the tox.ini file seems like the most sane choice.

Are you actually using "devpi test" or "tox", btw?

I've been a happy user of tox for a long time now, but I've only recently started investigating devpi's support for automated test suites, which explains why it took me a while to get up to speed in this discussion :-)


 - Peter