[Distutils] Where should I put tests when packaging python modules?
Ionel Cristian Mărieș
contact at ionelmc.ro
Tue Oct 6 18:04:54 CEST 2015
On Tue, Oct 6, 2015 at 6:33 PM, Erik Bray <erik.m.bray at gmail.com> wrote:
> Okay, though, so maybe if there is nothing to offer here but anecdata
> then maybe we should stop acting like there's "one right way here". I
> have projects that install their test suite and test dependencies
> because it is frequently useful to ask users to run a self-test (and
> users themselves want to be able to do it for a variety of reasons).
> There are other projects where it doesn't make sense, and those don't
> have to install the tests (I still think in those cases that the tests
> should live in the package instead of outside it, but simply not
To be honest, I like the idea of providing the tests in the installed
package. Using the test suite as a debugging/diagnostic tool is obviously
desirable. It's just that it's unpractical for general use. Another
anecdote I know, but humour these two concerns:
* How to deal with dependencies?
** Should we use extras? Installing test deps has the disadvantage of
version conflicts. Unless we make some sort of "virtualenv-for-tests" tool?
** Should we vendor the deps? But isn't that maybe too hard to do (or plain
wrong for other reasons)?
** Should we avoid having deps? That can be too limiting in some
situations, unittest is very bare compared to pytest or nose.
* What sort of tests should be included? Integration tests are special
case, if they need external services, temporary storage or what not. Would
we then need to have clear separation for different types of tests?
I'm not saying tests inside package is bad at all. But to flaunt it around
as a "best practice" requires at least some recommendations for the two
concerns illustrated above, and probably better tooling.
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG