Skip to content

exclude legacy dependencies when using python3 #85

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 14, 2018
Merged

exclude legacy dependencies when using python3 #85

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6b5d45b
exclude legacy dependencies when using python3
foxxx0 Apr 13, 2018
34664ef
🐛 Fix env markers by moving them to extras
webknjaz Apr 14, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion setup.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,6 @@
),
python_requires='>=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*',
install_requires=[
'backports.functools_lru_cache',
'six>=1.11.0',
'more_itertools>=2.6',
],
Expand All @@ -72,6 +71,13 @@
'codecov',

'pytest-cov',
],
':python_version<"3.3"': [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This introduction of ranged comparators in extras will create a (possibly backward-incompatible) expectation on the project to require Setuptools 17.1 or later. That's probably acceptable at this stage, but it should probably be declared in the changelog, or even better in a pyproject.toml. Personally, I'd like for these backports modules to be simply declared/included unconditionally.

completely useless bloat and possible saves users some time when not having to download and install something unnecessary.

The time to download a tiny module like this is small and it's mostly machine time, whereas the added complexity of the package declaration and the additional cognitive burden of that complexity consumes real human work.

I think I'd prefer the simpler declaration that avoids the need for environment markers and comments, even if it doesn't precisely define where the package is absolutely needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jaraco We install setuptools>=28.2 in Travis: https://github.com/cherrypy/cheroot/blob/6821264/.travis.yml#L156

Also Python 2.7.14 is shipped with setuptools==28.8.0: https://github.com/python/cpython/tree/v2.7.14/Lib/ensurepip/_bundled
(next patch release of 2.7.x should have https://github.com/python/cpython/tree/2.7/Lib/ensurepip/_bundled >=39.0.1)

So it looks okay to already use these features. (of course for envs where OS package manager controls things it might differ)

# functools_lru_cache has been added to stdlib in Python 3.2
# however it's only got support for ``typed`` arg in Python 3.3
'backports.functools_lru_cache',
],
'testing:python_version<"3.3"': [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've rejected this change before, because backports.unittest_mock is intended to be unconditionally included and it provides the conditionality (only including mock on the platforms where needed). In addition to making these dependency declarations more complicated in this project, it also implies that this is the rule that should be copied into every project that uses it. I reject that notion in that it violates DRY and adds to the cognitive burden of every project that uses it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you saying that we should revert it?

'backports.unittest_mock',
],
},
Expand Down