[Distutils] Where should I put tests when packaging python modules?

[Antoine Pitrou]

On Wed, 7 Oct 2015 00:47:31 +0300
Ionel Cristian Mărieș <contact at ionelmc.ro> wrote:
> On Tue, Oct 6, 2015 at 11:54 PM, Erik Bray <erik.m.bray at 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.

Is it your personal experience or some theoretical argument you're
making?

> If you install two packages with "inside" tests, then how do you deal with
> the version conflict of test dependencies?

Well, how do you deal with the version conflict of non-test
dependencies? How are tests supposed to be a problem here, while they
usually have so few dependencies of their own?

> If you have to bend over backwards (to install the test dependencies)

While some packages may have non-trivial test dependencies, usual
practice is for test suites to require the exact same dependencies as
the rest of the package, + perhaps a test runner.

Since we're talking about good practice for the average package, it's
not very useful to point out that 0.1% of PyPI packages may have
excruciatingly annoying test dependencies.

> Why completely mess up user's site-packages
> just because you want to have this weird `python -mfoobar.tests` workflow?

Did you have such an experience or are you making this up for the sake
of the argument?

And just because you are not used to a "workflow" doesn't make it
"weird" in any case.  Python itself uses such a workflow ("python -m
test").

Regards

Antoine.