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

Ionel Cristian Mărieș contact at ionelmc.ro
Tue Oct 6 23:47:31 CEST 2015

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. 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.

-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151007/361300a4/attachment-0001.html>

More information about the Distutils-SIG mailing list