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

Drop support for Python 2.6? #3955

Closed
dstufft opened this issue Sep 6, 2016 · 12 comments · Fixed by #4047
Closed

Drop support for Python 2.6? #3955

dstufft opened this issue Sep 6, 2016 · 12 comments · Fixed by #4047
Labels
auto-locked Outdated issues that have been locked by automation
Milestone

Comments

@dstufft
Copy link
Member

dstufft commented Sep 6, 2016

In a recent thread on distutils-sig I asked the larger packaging community when they thought it would be reasonable to kill Python 2.6 support.

I go into more detail on distutils-sig, but I feel like Python 2.6 is a bit of an albatross around our neck and it only accounts for ~3% of the traffic from PyPI when you look at "modern" versions of pip (i.e. 6+) and it itself has been end-of-life for 2013-10-29 or almost 3 years now.

I would like to drop support for Python 2.6 in pip, as of pip 8 we've had a pending deprecation/yellow warning that was intended to just stay there for as long as we felt appropriate and didn't nail us to any hard timeline except for "a future version of pip". In light of that, I'd say let's just bump that up to a deprecation/red warning in Pip 9 and remove it in pip 10.

Thoughts? Unless someone comes out against this I plan on moving forward with it.

@dstufft dstufft added this to the 9.0 milestone Sep 6, 2016
@dstufft
Copy link
Member Author

dstufft commented Sep 6, 2016

Oh I forgot to mention, the response in that thread was entirely positive about the idea of deprecating and dropping support for Python 2.6 over the span of ~4 days.

@dstufft
Copy link
Member Author

dstufft commented Sep 6, 2016

Oh and also, as far as benefits, besides being able to use more modern mechanisms that don't exist in Python 2.6 (but do exist in 2.7 and 3.3+) this will also free our dependencies from needing to continue to support 2.6. They may still elect to do this, but now they don't need to do it for our sake.

If we go forward with it, I'll also immediately adjust get-pip.py so that it better handles running on 2.6 and add a /2.6/ option like I added a /3.2/ option.

@Ivoz
Copy link
Contributor

Ivoz commented Sep 7, 2016

To clarify, declare 9.0 as last major version that will support 2.6?

@RonnyPfannschmidt
Copy link
Contributor

Lovely, can we have a timeline?

@dstufft
Copy link
Member Author

dstufft commented Sep 7, 2016

@Ivoz Yes.

@RonnyPfannschmidt We average 6-8 months between releases, so likely ~8mo-1y for it to be actually gone.

@dholth
Copy link
Member

dholth commented Sep 7, 2016

If I wanted to do this for bdist_wheel, could I rely on the requires-python tagging to get it done before pip?

@dstufft
Copy link
Member Author

dstufft commented Sep 7, 2016

Well, requires-python doesn't exist in a released version of pip yet.

@RonnyPfannschmidt
Copy link
Contributor

@dstufft nice, so we can drop 2.6 for pytest 4.0 maybe before

@gukoff
Copy link

gukoff commented Dec 9, 2016

Is the issue still planned?

@pfmoore
Copy link
Member

pfmoore commented Dec 9, 2016

@gukoff Not quite sure what you mean. The current pip 9 series deprecates Python 2.6 support, and pip 10 won't support 2.6. There's no confirmed release date for pip 10, but as noted above, 6-8 months after pip 9 was released is a good estimate. Is that what you wanted to know?

@gukoff
Copy link

gukoff commented Dec 9, 2016

The closing of the issue confuses me; I'd like to see the intention to drop Python2.6 support documented somewhere, but the only referenced PR which is merged has nothing to do with it.

If the latest releases explicitly deprecate it in code, it is already OK, thanks.

@pfmoore
Copy link
Member

pfmoore commented Dec 9, 2016

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants