reponses requires coverage < 4.0.0 but many systems ships coverage >= 4.0.0

[Germano0]

I am following a procedure that will bring responses inside official Fedora repositories.
responses needs coverage < 4.0.0 but Fedora 23 ships coverage 4.0.3, so during RPM package creation, when the system runs checks/tests I obtain errors

Traceback (most recent call last):
  File "setup.py", line 94, in <module>
    'Topic :: Software Development'
  File "/usr/lib64/python3.4/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib64/python3.4/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/usr/lib64/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/usr/lib/python3.4/site-packages/setuptools/command/test.py", line 134, in run
    self.distribution.fetch_build_eggs(self.distribution.tests_require)
  File "/usr/lib/python3.4/site-packages/setuptools/dist.py", line 313, in fetch_build_eggs
    replace_conflicting=True,
  File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 836, in resolve
    dist = best[req.key] = env.best_match(req, ws, installer)
  File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 1074, in best_match
    dist = working_set.find(req)
  File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 711, in find
    raise VersionConflict(dist, req)
pkg_resources.VersionConflict: (coverage 4.0.3 (/usr/lib64/python3.4/site-packages), Requirement.parse('coverage<4.0.0,>=3.7.1'))

Is there anything we can do?

[dcramer]

Personally I strongly disagree with packaging Python libraries with distros. The dependency hell that I've seen requests go through, along with the obvious fact that it simply doesnt work due to Python not supporting multiple lib versions, makes me very much against the pattern.

With that said, if you want to put the effort into ensuring it works with both coverage 3.x as well as 4.x, I'm not against bumping the requirements here.

[AdamWill]

Regardless your opinions about distribution packaging (I'd love to know how you think a distribution should write any of its core code in python if it can't package any libraries...), 'pinning' dependencies to outdated versions in this way is hardly a viable long-term strategy. It's not as if upstream coverage is supporting multiple major release series, they're not cutting 3.x releases or supporting them any more.

[AdamWill]

edit again - sorry for the bouncing, turns out I had an issue with an old pytest-flakes conflicting with new pytest.

With python 3.5.1, pytest 2.8.5, coverage 4.1b1, flakes 1.0.0, pytest-cov 2.2.0 and pytest-flakes 1.0.1, the py3 coverage test appears to work fine:

[adamw@adam responses (master *)]$ !6863
py.test-3 . --cov responses --cov-report term-missing --flakes
============================= test session starts ==============================
platform linux -- Python 3.5.1, pytest-2.8.5, py-1.4.30, pluggy-0.3.1
rootdir: /home/adamw/local/responses, inifile: setup.cfg
plugins: cov-2.2.0, flakes-1.0.1
collected 21 items 

responses.py s
setup.py s
test_responses.py s..................
---------------- coverage: platform linux, python 3.5.1-final-0 ----------------
Name           Stmts   Miss  Cover   Missing
--------------------------------------------
responses.py     183     17    91%   19-20, 23, 28-31, 50-55, 191, 201, 252, 258, 290-291

===================== 18 passed, 3 skipped in 0.19 seconds =====================

It also works fine if I skip --flakes (as per .travis.yml, so matching the travis runs) and produces identical output with both py2.7 and py3.5 as the travis run on the last master commit.

It may still not work with py3.2 or some other ancient py3 version, but does that really merit forcibly preventing the use of an up-to-date coverage in setup.py?

[dcramer]

@AdamWill we dont need to support 3.2 -- if you want to submit a PR with the change we can get it in. I'd prefer to keep it still version locked, but coverage.py has historically been good so im ok with saying <5.0

[AdamWill]

OK, thanks, I'll submit a PR and we'll see how the travis run goes.