Drop support for Python 2.6?

[dhermes]

I bring this up because cryptography now warns users still on Py2.6 as of 0.9.3 (which was released July 9)

$ python2.6
Python 2.6.9 (default, Oct 22 2014, 19:56:52) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cryptography
/usr/local/lib/python2.6/dist-packages/cryptography/__init__.py:25: DeprecationWarning: Python 2.6 is no longer supported by the Python core tea
m, please upgrade your Python.
  DeprecationWarning
>>> cryptography.__version__
'0.9.3'
>>> 
$ vanity cryptography
...
                 cryptography-0.9.3.tar.gz    2015-07-09       105316
cryptography-0.9.3-cp34-none-win_amd64.whl    2015-07-09          315
    cryptography-0.9.3-cp34-none-win32.whl    2015-07-09          382
cryptography-0.9.3-cp33-none-win_amd64.whl    2015-07-09          157
    cryptography-0.9.3-cp33-none-win32.whl    2015-07-09          170
cryptography-0.9.3-cp27-none-win_amd64.whl    2015-07-09        20267
    cryptography-0.9.3-cp27-none-win32.whl    2015-07-09        11954
cryptography-0.9.3-cp26-none-win_amd64.whl    2015-07-09          229
    cryptography-0.9.3-cp26-none-win32.whl    2015-07-09          589
---------------------------------------------------------------------
cryptography has been downloaded 5848426 times!
``

[dhermes]

They actually started warning at version 0.9 (released May 14, 2015)

[jgeewax]

I have no problem with us dropping formal support... especially if the Python core team dropped support....

[dhermes]

Quote from Alex Gaynor on the PR that added this:

Python 2.6 is no longer supported by the core development team, and we would like to drop support for it, so we're deprecating it.

@tseaver Do you know where an "official" announcement about core-dev support being dropped?

[tseaver]

The 2.6.9 (release announcement)[https://mail.python.org/pipermail/python-list/2013-October/658898.html] says:

Python 2.6.9 is a security-only source-only release, and with this, I officially retire the Python 2.6 branch. All maintenance of Python 2.6, including for security issues, has now ended.

[dhermes]

Interesting it happened almost 2 full years ago but cryptography only started warning a few months ago.

[tseaver]

Nick Coghlan (an influential Python core-dev) posted a Stop Supporting Python 2.6 for free blog post aimed at FLOSS developers: it landed in April 2015.

[dhermes]

I think this quote hits the nail on the head:

... I'm going to say it explicitly: if you're currently supporting Python 2.6 for free because folks using RHEL 6 or one of its derivatives say they need it, and this is proving to be a hassle for you, then stop. If they complain, then point them at this post, as providing an easily linkable reference for that purpose is one of the main reasons I'm writing it. If they still don't like it, then you may want to further suggest that they come argue with me about it, and leave you alone.

I'll whip up a PR to drop Py2.6 testing (and I think we have one or two hacks that can be dropped too).

[eamonnmcmanus]

I believe GCE has some OS images that have Python 2.6. I know this has been an issue for the Cloud SDK team. Could it be an issue for gcloud-python too?

[dhermes]

Chances are that those images are RHEL 6, which is the most well-known OS that ships a version less than 2.7 as the system Python (also mentioned in Nick Coghlan's post).

Our code supports Python 2.6 now, but this would just make us test fewer cases (faster "builds" on Travis and locally) and ditch a few weird hacks.

[eamonnmcmanus]

I'm confused as to what a successful resolution of this issue would be. Do we just say that Python 2.6 is unsupported, but continue to ensure that it works at least minimally? Or we do we say that it is unsupported and stop doing anything to ensure that it works? Because of course if it is the latter then it will quite quickly stop working.

[dhermes]

We say that it is unsupported and stop doing anything to ensure that it works

Regarding:

of course if it is the latter then it will quite quickly stop working

that's pretty unlikely. There are very few differences between Python 2.6 and 2.7 and our codebase already supports Python 3.3+ and Python 2.7 simultaneously.

As for continuing this discussion, @ncoghlan suggests

If they still don't like it, then you may want to further suggest that they come argue with me about it, and leave you alone.

[eamonnmcmanus]

There are very few differences between Python 2.6 and 2.7

I beg to differ. If anyone working on your code decides to use any of these features then it will suddenly no longer work on 2.6. If we're explicitly saying that gcloud-python will not be supported on RHEL 6 (including GCE's rhel-6 image) then that's fine, but otherwise I would suggest keeping at least one 2.6 configuration in the continuous build.

[tseaver]

Nick's post addresses the case that a FLOSS project has external (non-contributing / non-paying) users who desire 2.6 support. The difference here is that Google is paying for this development effort, and it may be in Google's interest to keep 2.6 compatibility (which is what @eamonnmcmanus is arguing).

Dropping 2.6 support would allow us to trim a testing dependency (unittest2), and to keep current with another (pycrypto) which is dropping it, as well as speeding up the CI turnaround. @jgeewax can you channel Google to determine relative weights?

[ncoghlan]

As @tseaver notes, GoogleCloudPlatform is an interesting case, as gcloud-python itself doesn't count as supporting Python 2.6 for free in my view (it's a developer facing component of a commercial service offered by Google), but the arguments in my post may apply to some of gcloud-python's dependencies (such as pycrypto).

Maintaining Python 2.6 compatibility is also getting more difficult with time, as there are a number of nice features that originally landed in Python 3.1 (like set literals, set and dictionary comprehensions, field autonumbering in str.format, collections.Counter and collections.OrderedDict) that were included in the original Python 2.7.0 release. and hence folks first learning Python with either Python 2.7 or any current version of 3.x are likely to take them for granted. collections.OrderedDict itself is actually available in RHEL 6.5+, but it's pretty easy to stumble over the others (for anyone that doesn't default to using printf-style string formatting, the lack of str.format field autonumbering is a particularly easy Python 2.6 incompatibility to hit)

Assuming that the main reason for retaining Python 2.6 compatibility is RHEL & CentOS 6, then a more fruitful path forward may be to encourage affected users that can't upgrade to RHEL or CentOS 7 to look at the softwarecollections.org project and the related Red Hat Software Collections component included in RHEL subscriptions. If folks don't want to invest time in upgrading the foundational layers of their stacks, then they can't reasonably expect to indefinitely keep upgrading higher level third party components.

[jgeewax]

Channeling the Googs -- There will be people who want to use RHEL 6 (for whatever scary reason), so this comes down to a question of cost (in dev time) since our job is "make it awesome to talk to Google Cloud stuff from Python".

That means, the big question is: How much extra work is it to continue with 2.6 support until... (let's say) the end of the year? And in Jan 2016 we can re-evaluate...

If we're talking about significant overhead, then I could make the argument that we should push people towards RHEL7.

[tseaver]

The real "cost" for us is that we may have to pin older versions of the dependency (cryptography) which is dropping 2.6 support eventually.

Deprecated support for Python 2.6. At the time there is no time table for actually dropping support, however we strongly encourage all users to upgrade their Python, as Python 2.6 no longer receives support from the Python core team.

I'd be fine with a similar note in our docs. A warning message, if we issue one, should be in setup.py, rather than every import.

[jgeewax]

OK - so we would need to globally pin to the old crypto version, there's no reasonable way to say "If you're using 2.7+, we can use this newer version", right? (I didn't think there was, but ... so much happens in the Python world...).

A warning message, if we issue one, should be in setup.py, rather than every import.

Definitely agree with this.

[dhermes]

@jgeewax We can do a sys.version check in setup.py. But using older versions of crypto libraries isn't usually a good idea, security being what it is and all.

[jgeewax]

If there's a vulnerability of sorts, and the crypto library says "yea, we don't support that version anymore, upgrade", then we have a much better argument for saying "we need version X of crypto, therefore you need version Y of Python".

Until then, my current feeling is to have to agree with @eamonnmcmanus and pitch that we should keep testing py2.6 until the end of the year and re-evaluate Jan 1, 2016. Still open for discussion though, so any other opinions are welcome....

[dhermes]

I'm fine with that. It's pretty minimal to support Py2.6 at the moment (requires 0 dev effort and about 0.5 seconds of unit testing per local run and 10s per Travis run). Was just trying to be good for Python dev (based on Nick's post) and originally just concerned by the scary warning in cryptography.

[ncoghlan]

The problematic aspect of using Python 2.6 (and any version earlier than 2.7.9, really) is the secure networking support in the standard library - as PEP 466 spells out, the default settings are positively archaic. Using pycrypto instead actually alleviates a lot of those problems, but it's still hard to ensure that dependencies aren't relying on the outdated default behaviours in the standard library modules.

For the time being, the DeprecationWarning approach sounds like a good idea to me - PEP 493 spells out some of the current issues with rolling out the PEP 466 and PEP 476 network security improvements across all widely available versions of Python 2.7, but as those get addressed, then continuing to use Python 2.6 for any activity involving the public internet will be a genuinely bad idea.

[dhermes]

@jgeewax More "evidence": the latest version of django supports neither 2.6 nor 3.3. In particular

• 3.2 and 3.3 support were dropped in 1.9 (the current version release Dec. 1, 2015)
• 2.6 support was dropped in 1.7 (released Sept. 2, 2014)

(In #1290 I had to add a backport for a datetime feature not in Py2.6)

[dhermes]

@jgeewax Bump. WDYT? (Just filed #1410 in related announcement issue)

[jgeewax]

I think we have enough here to move forward. The short version is:

• If someone tries to use this with Python 2.6, we should show them a warning saying "you really shouldn't be doing this".
  • If they find bugs that are easy to fix for Py26, we should give them a fair shake, but can't promise to deal with everything.
  • When we have to choose between Py26 and Py27, we go with Py27
• Testing dependencies that "would go away by dropping Py26 support" probably shouldn't get chopped "just because we can". Adding an extra dep really isn't that big of a deal.
• If possible, it'd be nice to keep running Py26 tests, so that we can fix things in the spirit of the first item on this list.

Otherwise, I think it's fine to say "No more Python 2.6 as a first-class citizen" (App Engine only talks about Python 2.7 in their docs now).

[tseaver]

If we issue the warning (preferably when running setup.py under Python 2.6), we should announce that we will drop support at a specific point in the future (a 1.1 release, maybe?)

[dhermes]

Some things to note

• 2.6 was never supported on GAE, it went straight from 2.5 to 2.7
• The cryptography library prints a foreboding warning

.tox/py26/lib/python2.6/site-packages/cryptography/__init__.py:26:
DeprecationWarning: Python 2.6 is no longer supported by the Python
core team, please upgrade your Python. A future version of cryptography
will drop support for Python 2.6

• We have a backport in existence for missing features in Python 2.6 (unittest2 is also essentially a backport)
• Getting people off of 2.6 is the "right" way to be part of the Python ecosystem

I am 👍 on the warning and future removal of support.

[dhermes]

@tseaver Can you help cut the final 2.6 release and update the docs / README / etc?

Today is DERP-recation day!

[tseaver]

In favor or #1607.