On Tue, Oct 6, 2015 at 11:54 PM, Erik Bray <erik.m.b...@gmail.com> wrote:
> Skimming back through the rest of the thread I don't see too much > support for 1). The only argument against it is the need for > specifying dependencies, etc., which really only impacts developers so > long as the tests aren't *installed*, I think. But there's also the > question of what kinds of tests we're talking about. I think unit > tests should live in the <packagename>.tests for a library. Other > kinds of tests I don't have a strong opinion about. > I think there's some confusion here. The pain point with "inside" tests is exactly the dependencies. And by dependencies I mean test dependencies, we're talking about tests here :-) If you install two packages with "inside" tests, then how do you deal with the version conflict of test dependencies? That's the big elephant in the room everyone is ignoring :) If you have to bend over backwards (to install the test dependencies) in order to run the installed tests then what's the point of installing them at all? It's far more safer to ask the user to just checkout the sources and run the tests from there. Why completely mess up user's site-packages just because you want to have this weird `python -mfoobar.tests` workflow? I like the idea, I really do. But it's not for everyone. I strongly feel that only projects that don't have any test dependencies should install the tests, or provide the tests inside the package. Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig