On Wed, Oct 7, 2015 at 1:04 AM, Antoine Pitrou <solip...@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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig