Only require backports.functools_lru_cache for python < 3.3

[dcermak]

❓ What kind of change does this PR introduce?

• 🐞 bug fix
• 🐣 feature
• 📋 docs update
• 📋 tests/coverage improvement
• 📋 refactoring
• 💥 other

📋 What is the related issue number (starting with #)

None

❓ What is the current behavior? (You can also link to an open issue here)

cheroot requires the backports.functools_lru_cache module even for python versions that ship functools.lru_cache

❓ What is the new behavior (if this is a feature change)?

cheroot only requires backports.functools_lru_cache for python < 3.3

📋 Other information:

📋 Checklist:

• I think the code is well written
• I wrote good commit messages
• I have squashed related commits together after the changes have been approved
• [-] Unit tests for the changes exist
• [-] Integration tests for the changes exist (if applicable)
• [-] I used the same coding conventions as the rest of the project
• [-] The new code doesn't generate linter offenses
• [-] Documentation reflects the changes
• [-] The PR relates to only one subject with a clear title
  and description in grammatically correct, complete sentences

---

This change is 

[codecov]

Codecov Report

Merging #221 into master will decrease coverage by 2.16%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #221      +/-   ##
==========================================
- Coverage   74.13%   71.97%   -2.17%     
==========================================
  Files          23       23              
  Lines        3507     3507              
==========================================
- Hits         2600     2524      -76     
- Misses        907      983      +76

[smithfarm]

@webknjaz Was the "wontfix" label added intentionally?

[smithfarm]

This fixes the following bug - on a system with a recent Python 3 installed:

$ python3
>>> import pkg_resources; pkg_resources.require('cheroot')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 895, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 781, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'backports.functools_lru_cache' distribution was not found and is required by cheroot

(In other words, without this fix, cheroot is totally broken on recent Python 3.)

[webknjaz]

@smithfarm it's not broken. You didn't install the dependency.

[webknjaz]

I'm leaving this up to @jaraco to decide whether to merge this. It's a duplicate of what he blocked two times already.

[smithfarm]

@smithfarm it's not broken. You didn't install the dependency.

It's not a problem for me, personally. The problem arises in openSUSE Leap 15.1 which does not package "backports.functools_lru_cache" for Python 3 for what seems like a good reason - the code it contains is included in Python 3 core.

[webknjaz]

@smithfarm it's a fallback in runtime. But pkg_resources seems to disagree. That dep is noop under Python 3.

[webknjaz]

Anyway, I'm almost sure that you didn't use Pip to install Cheroot which means that you must blame your OS packager.

[webknjaz]

It's a duplicate of #181 and #203

[smithfarm]

Anyway, I'm almost sure that you didn't use Pip to install Cheroot which means that you must blame your OS packager.

Right, I am trying to keep this stuff running in the OS.

If this fix helps the OS maintainers and does not hurt folks using pip, I don't understand why it's being blocked?

[webknjaz]

ea8acd0

[webknjaz]

Feel free to read all the discussions in linked tickets. But the bottom line is that we only support Pip and separate ourselves from anything that is related to OS cases because it's something that somebody else who is interested in this should maintain.

[dcermak]

But the bottom line is that we only support Pip and separate ourselves from anything that is related to OS cases because it's something that somebody else who is interested in this should maintain.

I fully understand that.

What I don't understand is why you insist on keeping backports.functools_lru_cache as a direct dependency for Python versions that ship this module in their standard library? Yes, the installation is not broken with pip (because it just downloads the package but never uses it) and yes we can work around this dependency when creating a rpm package, but that's not the point of this pull request. The point is that you do not need backports.functools_lru_cache as lru_cache is part of functools since Python 3.2. So why require it then?

[jaraco]

That reversion commit mentions #85.

[dcermak]

Suggested change

	- Revisit :pr:`85` under :pr:`221`. Now ``backports.unittest_mock``
	- Revisit :pr:`85` under :pr:`221`. Now ``backports.functools_lru_cache``

[jaraco]

Added in 2f6199a

[jaraco]

Added in 2f6199a

[jaraco]

So why require it then?

Reading up on #85, which goes into detail, the tl;dr is that it's simpler for this project (and all other projects) to unconditionally declare these compatibility libraries and in fact, the backports guidance specifically advises projects to unconditionally use the backport (see "What if the feature is present"). Cheroot doesn't do that, which is what gives the impression that it's an optional dependency. It's the declared dependencies that are authoritative, so if downstream packagers aren't honoring the declared dependencies, that's a bug in their system.

So let's say we accept this proposal. Does that make it easier for downstream packagers? It arguably makes it more difficult, as now packagers have different dependency trees depending on the target Python version.

Still, since cheroot is conditionally importing this dependency, I guess it's fine to accept to make it easier on the packagers.

[dcermak]

Does that make it easier for downstream packagers?

Thank you for merging this, it actually makes our job easier in opensuse.