Make pytest-runner conditional

[koobs]

pytest runner should not be unconditionally included in setup_requires

This change makes it conditional on setup.py invocation arguments as recommended upstream [1]

See: pytest-dev/pytest#3814

Identified via: FreeBSD Ports Bug 242065

Closes #417
Closes #420

[1] https://pytest-runner.readthedocs.io/en/latest/#conditional-requirement

[blueyed]

I wonder if it shouldn't be removed completely? (as it appears to have been the plan with #417)

[ngie-eign]

@blueyed: I personally would prefer pytest-runner for end-user usability/consistency, and as a packager, having to install tox to run the tests requires a different raft of packages than pytest-runner would increase the package dependency footprint on a test host.

[koobs]

@blueyed: I personally would prefer pytest-runner for end-user usability/consistency, and as a packager, having to install tox to run the tests requires a different raft of packages than pytest-runner would increase the package dependency footprint on a test host.

+1 and likewise, and not only from a dependency footprint, but more importantly, tox isn't a required test dependency for 'distribution', in the sense that it is just a wrapper to run other test tools (pytest, nose, unittest, et al) and provides isolation and other features relevant to 'development'.

Any forced requirement to use tox outside of development, just makes testing packages that much harder, as we (users, packagers, non-development consumers) need to:

• Test against the python packages the system provides or has installed (not what is specified by tox or requirements.txt)
• Disable network dependency resolution/fetching (isolated / clean room builds and testing)
• Jump through hoops to get packages to test against (inherit from) the system Python environment

The distinction between development testing automation, and end user / consumer test-ability against what the system (packages) provides is key, same as there is a distinction between setup.py:*_requires for distribution and requirements.txt for deployment.

[justinmk]

@ngie-eign @koobs how does that square with https://github.com/pytest-dev/pytest-runner#deprecation-notice ?

[justinmk]

@blueyed coverage tool looks broken, any idea how to fix it?

[blueyed]

@blueyed coverage tool looks broken, any idea how to fix it?

Might be a bug/issue with the new Coveragepy 5.
#421 works around / fixes it.

[ngie-eign]

@ngie-eign @koobs how does that square with https://github.com/pytest-dev/pytest-runner#deprecation-notice ?

:(... I kind of liked the support, but what can I say? I'm not the upstream pytest-runner maintainer :/..

[koobs]

@ngie-eign @koobs how does that square with https://github.com/pytest-dev/pytest-runner#deprecation-notice ?

Yeh, it's getting harder as a downstream consumer/user to continue to fight for some notion of a 'canonical test command' in Python packages that 'just works', without having to waste time searching upstream documentation for how to run tests, test dependencies, etc

Nevertheless, thank you for taking care of this