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

Deprecate/Drop Support for Python 3.3? #3796

Closed
dstufft opened this issue Jun 13, 2016 · 8 comments · Fixed by #4355
Closed

Deprecate/Drop Support for Python 3.3? #3796

dstufft opened this issue Jun 13, 2016 · 8 comments · Fixed by #4355
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@dstufft
Copy link
Member

dstufft commented Jun 13, 2016

Currently Python 3.3 support is not a major headache for support (unlike 3.2) because we're largely being limited by Python 2.6 and 2.7 in terms of what features we can support. However, I think it's important to periodically look at the usage and make sure that we're not supporting Python versions that are not really being used as no matter what, each version of Python we support incurs a cost in terms of overhead for support (more build matrix items, minor incompatibilities, etc).

With that in mind, I took a look at what % of the pip initiated traffic that PyPI received in the last month to see what our usage numbers look like.

Only pip 8 initiated traffic:

2.7 83.8%
3.5  6.3%
3.4  5.5%
2.6  3.8%
3.3  0.3%
3.6  0.1%
3.2  0.03%

All pip initiated traffic:

2.7 86.8%
3.4  5.2%
3.5  3.9%
2.6  3.4%
3.3  0.4%
3.2  0.07%
3.6  0.04%

Given that 3.3 support is well under 1%, do we want to deprecate support for Python 3.3 with intent to drop support for it in either pip 9 or pip 10? For myself, I say yes-- either as a pip 9 or a pip 10 deprecation.

@pypa/pip-committers ?

@xavfernandez
Copy link
Member

xavfernandez commented Jun 13, 2016

Since it is not particularly painful to keep 3.3, I'd say we should keep supporting it until its end of life i.e. September 2017 which could correspond approximately to pip 10 release since we usually have a major pip version every 6 months or so.

@dstufft
Copy link
Member Author

dstufft commented Jun 13, 2016

So maybe make a special deprecation like we have for Python 2.6 and just remove it in the next major version we release after September 2017?

@RonnyPfannschmidt
Copy link
Contributor

i propose keeping it up until pypy manages to catch up

@xavfernandez
Copy link
Member

So maybe make a special deprecation like we have for Python 2.6 and just remove it in the next major version we release after September 2017?

It seems fine to me.

On the other end, Python 3.3 is not supported any more for bugfix, only for security updates so dropping its support in the next major could also be done.

Whatever we choose, we should try to deal with it more gracefully:

  • Do not prompt for upgrade message in 3.3 if the next version is the major known to drop support for 3.3
  • Implement Python-Requires in the mean time to prevent 3.3 user from upgrading to an unsupported version of pip

@pfmoore
Copy link
Member

pfmoore commented Jun 14, 2016

For Python 3.x releases I don't think we should support anything that is no longer supported by python-dev (see https://docs.python.org/devguide/#status-of-python-branches). That means 3.3+ at the moment. I don't have a problem with being a little more aggressive than that if there's a benefit for us in doing so, but I'm not sure dropping 3.3 gives us anything much.

I'll leave the question of 2.x support for others (my views are basically as above, follow python-dev, but that's more aggressive than current policy :-))

As regards the point @RonnyPfannschmidt made about PyPy, I'm not sure PyPy3 is worth worrying about yet (can we get PyPy vs CPython download figures?) - they don't seem to have any published release schedule or plans for tracking CPython 3 versions, so we'd in effect be pinning support for an old CPython version indefinitely (or at least until we decide to ignore PyPy3 at some later date). I'd rather we took the view that we support PyPy to the extent that they are compatible with one of the Python versions we support.

But I do agree with @xavfernandez that we need to improve our desupport process, so that if someone is on a version that's no longer supported, they can't accidentally upgrade to a pip version that they can't use, and they don't get nagged to do so.

@dstufft
Copy link
Member Author

dstufft commented Mar 20, 2017

I think I'm going to go ahead and drop support for 3.3 for the next major version of pip (10.0). We're only a couple of months away from 3.3 being EOL with upstream and they haven't released a new version since 2014-10-12 anyways so while it is supported, I would argue that it is more like "supported". In addition PyPy3 is soon to have a 3.5 compatible release, so that is no longer a reason to keep this around.

Ultimately though, I think the usage just doesn't warrant spending much effort in keeping it here.

@xavfernandez
Copy link
Member

I think I'm going to go ahead and drop support for 3.3 for the next major version of pip (10.0).

Do you mean that pip 9.0.1 will be the last to support 3.3 or will pip 10 be the last ?

I'm much more in favor of the second solution.
We'd add DepreciationWarning in pip 10 saying it will be the last supporting 3.3 to give the (very) few people still using 3.3 a heads up.

What is to gain to drop 3.3 right away ? (Except one less Travis build)

@dstufft
Copy link
Member Author

dstufft commented Mar 20, 2017

Sure that works for me. The main thing to gain is one less Travis build :)

carsonyl added a commit to carsonyl/pypac that referenced this issue Feb 21, 2018
'py' 1.5.x dropped support: pytest-dev/py#165
py is a transitive dependency.

pip shows low usage: pypa/pip#3796
ovasquez pushed a commit to ovasquez/mkdocs-merge that referenced this issue May 29, 2018
houglum added a commit to houglum/apitools that referenced this issue Sep 7, 2018
Pip no longer supports Python 3.3:
pypa/pip#3796

Python 3.3's end of life was roughly a year ago anyway, so
this seems like a good time to drop it from the test matrix:
https://www.python.org/dev/peps/pep-0398/#x-end-of-life
@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.

4 participants