On Tue, Oct 6, 2015 at 6:33 PM, Erik Bray <[email protected]> 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 > installed). 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. Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
