Python 2.7 Deprecation Timeline

[reaperhulk]

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:

• Support 2.7 as first class through end of 2019.
• Bug fix/security patch on an LTS until Dec 31, 2021.

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).

[alex]

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.

[reaperhulk]

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 cryptography releases to encourage upgrades by breaking old pip and setuptools. Supporting these older versions were not maintenance burdens on us -- in fact, breaking those old versions imposed non-zero cost to the project, but you convinced me that it was worth doing to push the ecosystem forward. Upgrading those is, of course, easier than migrating to Python 3, but the idea is to create deadlines users can make decisions based on.

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 pip development starting Jan 1, 2020 though 😄

[alex]

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.

[dstufft]

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, pip install <foo> will install the latest that works on your machine).

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.

[reaperhulk]

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.

[intgr]

Python 2.7's EOL is approaching :) and I was wondering about the same question. Is it time to revisit this?

[alex]

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.

[h-vetinari]

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.