-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Python 2.7 Deprecation Timeline #4022
Comments
Right now we're at 80% Python2 usage. We haven't even done our release which drops 2.6 to know how that will go. As you know, I hate LTS. Python2 is not a maintenance burden. This is premature. |
A deprecation timeline is significantly different than our past policy of starting to warn users and then dropping support with a ~2 release warning. I believe a timeline gives users actionable information about what they need to do and helps other projects that may be on the fence make decisions about their own support (see: every time we drop support we talk about other projects that are dropping support). In the past we've used I think establishing a sunset date for Python 2 support is a reasonable action. It may be that we choose to extend our timeline based on rates of drop off (I certainly don't want to drop support if we're staring down the barrel of double digit percentage downloads as we near the deadline), but if this project wants to continue to try to push forward the Python ecosystem we should be willing to at least attempt to draw a line in the sand. Call it an aspirational deprecation timeline. The above kind of assumes that by establishing such a deadline other high profile projects might choose to follow suit. Maybe it makes sense to reach out and see if there's any interest in a rough shared timeline -- if not then the point may be moot. I am definitely curious what @dstufft's plan is for |
I think we're unlikely to be effective. Most people use cryptography via some other package: certbot, twisted, paramiko, etc. Those projects have a direct relationship with their users and are likely to be more effective at pushing people. |
The idea behind a shared timeline reminds me of http://www.python3statement.org/, and many of them used the idea of creating a LTS to handle Python 2.x users (and with modern pip, doing so is not an unpleasant experience, We don't really have a plan to drop support for Python 2.7 in pip because largely we haven't really discussed what to do about it. Generally in the past our deprecation timelines were driven by usage and thus they've generally been descriptive rather than prescriptive. I don't know how Python 2.7 is going to "die" in that regards, if we'll need to effectively draw a line in the sand and say that after this, no more, or if we'll be able to treat it like we've treated every other version of Python, and remove it when the number of users reached some sort of minimal mass. Cryptography is kind of in a weird place, because i think one of the big drivers of usage for this is the attempt to backport newer ssl features to older versions of Python, particularly Python 2.7. Twisted uses PyOpenSSL (which uses cryptography) in order to gain access to things like MemoryBIOs. I believe that Twisted could work entirely with the stdlib ssl module in Python 3.something+. Requests/urllib3 also uses this to backport things like SNI support or modern OpenSSL to older versions of Python. That doesn't mean that cryptography can never drop Python 2.7 support, but it does indicate that the usage pattern for cryptography might be one that dropping Python 2.7 support might also mean a number of users simply no longer need to use cryptography. Beyond the above, I don't really have an answer or a fully formed opinion on when/if cryptography should drop support for Python 2.7. |
Since I'm the only one who appears interested in this I'll go ahead and close it for now. We can revisit as Python 2.7's EOL approaches. |
Python 2.7's EOL is approaching :) and I was wondering about the same question. Is it time to revisit this? |
Our downloads are still around 1/3 Python2: https://pypistats.org/packages/cryptography We intend to follow the data on this, I think until we're closer ot 10% or so there's no action to be taken here. |
Since pip was mentioned as a reference, it may be worth mentioning that they will drop python 2 support by January 2021, with 3 versions announcing the phase out in advance. |
numpy recently published a deprecation timeline for Python 2.7 support. Should we try to do something similar?
Here's a straw man for discussion:
Potential problems include the fact that we've never done an LTS so we'll have to talk about what that might really entail, and that the timeline above runs past upstream CPython's 2.7 support by a year. Of course, there is precedent there in that OpenSSL 1.0.1 is no longer supported by upstream but we have no real timeline for removal of support since several widely used distributions still have it (and hypothetically backport security fixes).
The text was updated successfully, but these errors were encountered: