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

[Ionel Cristian Mărieș]

On Wed, Oct 7, 2015 at 1:04 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> > ​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?
>

I've published about 27 packages that have tests on PyPI. Out of those only
5 could run purely on stdlib unittest.​

That leaves me with 22 packages that need test tools like pytest/nose and
assorted plugins.


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

​It's double the trouble to find compatible releases. Current tooling don't
resolve conflicts automatically.​ Maybe it's something handled better in
Conda for all I know but I don't use that.


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

Can't relate to that - definitely not `usual practice` from my perspective.​


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

​Already feeling guilty ... I hope you're finally happy now :-)
​


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

​I got burnt by the pbr issue [1] once (cause mock has it as a run-time
dependency). I don't normally use `mock` but in the circle of hell I live
in someone else depended on it.​


​I don't look forward to that happening again, and I don't want to litter
my site-packages with useless test stuff. I already have too much stuff in
there.



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


​It's weird in the sense that you have to do all these gymnastics to get
the test dependencies right​

​before running that. As I previously stated, I like the idea of `python
-mfoobar.test` - just that dependencies and scope make it weird and
impractival for *general* use.

​[1] https://bugs.launchpad.net/pbr/+bug/1483067​



Thanks,
-- 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/c43e0572/attachment-0001.html>