Skip to content
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.

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

Remove support for EOL Python 3.5 and 2.7 #1243

Merged
merged 9 commits into from Dec 31, 2020
Merged

Remove support for EOL Python 3.5 and 2.7 #1243

merged 9 commits into from Dec 31, 2020

Conversation

jdufresne
Copy link
Member

Python 3.5 went EOL 2020-09-30.

For a list of supported Python versions, see:
https://devguide.python.org/#status-of-python-branches

For a list of EOL Python versions and their dates, see:
https://devguide.python.org/devcycle/#end-of-life-branches

Contributor checklist
  • Provided the tests for the changes.
  • Gave a clear one-line description in the PR (that the maintainers can add to CHANGELOG.md on release).
  • Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

@jdufresne jdufresne added this to the 6.0.0 milestone Nov 25, 2020
@jdufresne
Copy link
Member Author

I marked this for the 6.0.0 milestone, but I'm not sure if that is considered correct.

This change was suggested in #1222.

I'll also copy over my questions from that PR, so the thread can continue here:

What is the pip-tools policy on supported Pythons?

If we're using EOL as a guideline, then we should begin work towards dropping Python 2. Something I'm happy to contribute to. See https://devguide.python.org/#status-of-python-branches

Or, on the other hand, are we trying to match the pip support? If so, they still support Python 3.5.

Or, is the policy to drop EOL Pythons except 2.7?

I looked through the docs and wasn't able to find anything explicit. I could add something to https://github.com/jazzband/pip-tools#versions-and-compatibility once I understand the policy.

My preference is to follow Python EOL schedule, but I recognize that may be too fast for some projects that use pip-tools.

@atugushev
Copy link
Member

I marked this for the 6.0.0 milestone, but I'm not sure if that is considered correct.

That's correct. See 4.0.0 release for example.

What is the pip-tools policy on supported Pythons?

Usually pip-tools follows pip drop guideline. BTW pip==20.1 drops py3.5, see pypa/pip#8778.

I looked through the docs and wasn't able to find anything explicit. I could add something to https://github.com/jazzband/pip-tools#versions-and-compatibility once I understand the policy.

Cool! That would be awesome!

@jdufresne jdufresne added the backwards incompatible Backwards incompatible change label Nov 26, 2020
@hugovk
Copy link
Member

hugovk commented Nov 26, 2020

Usually pip-tools follows pip drop guideline. BTW pip==20.1 drops py3.5, see pypa/pip#8778.

Typo: it's actually pip==21.0 which will drop 3.5, in January 2021, and the same version will also drop 2.7 (pypa/pip#8087 / pypa/pip#6148).

@jdufresne
Copy link
Member Author

@atugushev If we're going make a new major release with backward incompatible changes, WDYT about taking this opportunity to drop Python 2?

Python 2 has now been EOL for nearly a year.

Python 2 users could continue using old version of pip-tools until they're ready to upgrade their project. We could even cut one more minor release so Python 2 users have one more chance to receive updated features (such as the new pip compatibility).

Removing it would reduce compatibility code, CI resources, and other maintenance concerns. As well, we could begin to take advantage of newer Python features and patterns. pytest, click, and other transient dependencies have removed or are removing Python 2 support.

Here are the PyPI statistics for the last three months. It shows Python 2 downloads before 20% and this percentage has been falling.

python_version percent download_count
3.7 29.78% 800,411
3.8 22.67% 609,187
2.7 19.96% 536,354
3.6 18.39% 494,225
3.5 7.15% 192,166
3.9 1.96% 52,628
3.4 0.09% 2,371
3.10 0.01% 382
3.3 0.00% 31
2.6 0.00% 7
Total 2,687,762

I'm am willing to do the necessary work. Cheers.

@atugushev
Copy link
Member

@jdufresne

If we're going make a new major release with backward incompatible changes, WDYT about taking this opportunity to drop Python 2?

Since pip==21.0 drops py27 we should drop it also.

@jdufresne
Copy link
Member Author

Great to hear! The latest revision of this PR drops Python 2.7 as well.

setup.cfg Outdated Show resolved Hide resolved
@hugovk
Copy link
Member

hugovk commented Nov 30, 2020

test_sync.py has a couple of asserts with 2.7 checks:

def test_diff_should_install_with_markers(from_line):
    installed = []
    reqs = [from_line("subprocess32==3.2.7 ; python_version=='2.7'")]

    to_install, to_uninstall = diff(reqs, installed)
    assert {str(x.req) for x in to_install} == (
        {"subprocess32==3.2.7"} if sys.version.startswith("2.7") else set()
    )
    assert to_uninstall == set()


def test_diff_should_uninstall_with_markers(fake_dist, from_line):
    installed = [fake_dist("subprocess32==3.2.7")]
    reqs = [from_line("subprocess32==3.2.7 ; python_version=='2.7'")]

    to_install, to_uninstall = diff(reqs, installed)
    assert to_install == set()
    assert to_uninstall == (
        set() if sys.version.startswith("2.7") else {"subprocess32"}
    )

Also pyupgrade is intentionally timid in upgrading to f-strings, https://github.com/ikamensh/flynt (optionally with -a) is good at converting more.

@jdufresne
Copy link
Member Author

Thanks for the review @hugovk I applied your suggestions in the latest revision.

@jdufresne jdufresne mentioned this pull request Dec 3, 2020
3 tasks
@codecov
Copy link

codecov bot commented Dec 4, 2020

Codecov Report

Merging #1243 (f63953e) into master (25492a2) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1243      +/-   ##
==========================================
- Coverage   99.66%   99.65%   -0.01%     
==========================================
  Files          37       36       -1     
  Lines        2980     2919      -61     
  Branches      331      325       -6     
==========================================
- Hits         2970     2909      -61     
  Misses          5        5              
  Partials        5        5              
Impacted Files Coverage Δ
piptools/__init__.py 100.00% <ø> (ø)
piptools/click.py 100.00% <ø> (ø)
piptools/locations.py 100.00% <ø> (ø)
piptools/repositories/local.py 96.22% <ø> (-0.07%) ⬇️
piptools/scripts/sync.py 100.00% <ø> (ø)
tests/utils.py 100.00% <ø> (ø)
piptools/cache.py 100.00% <100.00%> (ø)
piptools/exceptions.py 100.00% <100.00%> (ø)
piptools/logging.py 100.00% <100.00%> (ø)
piptools/repositories/base.py 100.00% <100.00%> (ø)
... and 17 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 25492a2...f63953e. Read the comment docs.

@jdufresne jdufresne changed the title Remove testing for EOL Python 3.5 Remove support for EOL Python 3.5 and 2.7 Dec 5, 2020
@jdufresne jdufresne mentioned this pull request Dec 16, 2020
16 tasks
https://github.com/asottile/pyupgrade

Cleanups:

- set comprehension
- drop default open() argument
Python 3.5 went EOL 2020-09-30.

For a list of supported Python versions, see:
https://devguide.python.org/#status-of-python-branches

For a list of EOL Python versions and their dates, see:
https://devguide.python.org/devcycle/#end-of-life-branches
Python 2.7 went EOL 2020-01-01.

For a list of supported Python versions, see:
https://devguide.python.org/#status-of-python-branches

For a list of EOL Python versions and their dates, see:
https://devguide.python.org/devcycle/#end-of-life-branches

Removing support reduces compatibility code, CI resources, and other
maintenance concerns. As well, can begin to take advantage of newer
Python features and patterns.

Cleanups:

- Use f-strings
- Drop __future__ imports
- Drop file encoding cookies "# coding: utf-8"
- Drop uses of six
- Use stdlib TemporaryDirectory and unittest.mock
- Use newer metaclass syntax
- Drop now unnecessary fs_str() function
- Drop inheritance from "object", all Python 3 classes are new-style
  classes
- Remove unnecessary coerce to string/bytes calls
- Use updated subprocess APIs
- Monkey patch sys.stdin using io.StringIO(). This avoids the need to
  use yet-another-tool rather than the tools providing by the test
  library.

- This reduces indentation to slightly improve readability.

- Allows for more accurate assertion of stdout and stderr.
capfd was used to workaround a compatibility issue between Python 2,
Windows and Click. With Python 2 gone, can use capsys.
Introduced in Python 3.5
@jdufresne jdufresne mentioned this pull request Dec 30, 2020
3 tasks
Copy link
Member

@atugushev atugushev left a comment

Choose a reason for hiding this comment

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

Awesome!

This was referenced Mar 16, 2021
bmwiedemann pushed a commit to bmwiedemann/openSUSE that referenced this pull request Mar 22, 2022
https://build.opensuse.org/request/show/962444
by user mcepl + dimstar_suse
- version update to 6.5.1
  Backwards Incompatible Changes:
  - Remove support for EOL Python 3.5 and 2.7
    ([#1243](jazzband/pip-tools#1243)). Thanks @jdufresne
  - Remove deprecated `--index/--no-index` option from `pip-compile`
    ([#1234](jazzband/pip-tools#1234)). Thanks @jdufresne
  See CHANGELOG.md for more
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backwards incompatible Backwards incompatible change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants