Nick might have something better to say about this, but I don’t think catching enterprise-y linux distros like RHEL out of the blue is a good way to go, so even if we decide right now to drop 2.6 support, it shouldn’t actually ship with breaking changes for like... 3 months? Maybe a little more or little less.

-----Original Message----- From: Distutils-SIG [mailto:distutils-sig-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Donald Stufft Sent: Friday, September 2, 2016 5:06 PM To: distutils sig Subject: [Distutils] When can we kill Python 2.6 support?

The packaging tools generally support 2.6+ and 3.(2|3)+ and that's sort of been where they've been at for a while now. I would like to think about what we need to be to start considering Python 2.6 as "too old" to support. In pip we generally follow a usage based deprecation/removal of supported Pythons but we don't have any real guidelines for when something is at a low enough usage to consider it no longer supported and we instead just sort of wait until someone makes a case that it's "low enough".

This issue tends to impact more than just pip, because once pip drops support for something people tend to start dropping it across the entire ecosystem and use pip's no longer supporting it as justification for doing so.

I would like to take a look at Python 2.6 and try and figure out if we're at a point that we can deprecate and drop it, and if not what is such a point.

Looking at pure usage numbers for "modern" versions of pip (6, 7, and 8) for downloading from PyPI I see the usage is ~3% of downloads are via Python 2.6. The only thing lower than Python 2.6 that is still supported is Python 3.3.

Python 2.6 itself has been EOL since 2013-10-29 which is now just about 3 years ago. It's SSL module is not generally secure and requires the use of additional installed modules to get it to be so. I believe the only place to get a Python 2.6 that is "supported" is through the Enterprise-y Linux Distributions like RHEL/CentOS/etc.

Do we think that a ~3% usage of Python 2.6 and being end-of-life'd for ~3 years is enough to start deprecating and dropping 2.6? If not what sort of threshold do we think is enough? It'd be nice to get the albatross of Python 2.6 support off from around our necks but I'm not sure how others feel. Obviously all of the existing versions of all of the tooling will still be fully functional so Python 2.6 users will simply need to not upgrade their tooling to continue to work, *but* it also means that they will be left out of new packaging features (and likewise, people can't rely on them if they still wish to support 2.6).

Thoughts?

— Donald Stufft

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Therein lies my suggestion. Pick a date, announce, give 3 months, then stop testing on 2.6

-----Original Message----- From: Donald Stufft [mailto:donald@stufft.io] Sent: Friday, September 2, 2016 6:18 PM To: tritium-list@sdamon.com Cc: distutils sig Subject: Re: [Distutils] When can we kill Python 2.6 support?

...

On Sep 2, 2016, at 5:47 PM, tritium-list@sdamon.com wrote:

Nick might have something better to say about this, but I don’t think catching enterprise-y linux distros like RHEL out of the blue is a good way to go, so even if we decide right now to drop 2.6 support, it shouldn’t actually ship with breaking changes for like... 3 months? Maybe a little more or little less.

Right, I don’t specifically mean immediately ejecting support, but rather deprecate and then drop along whatever the normal timeline is for project (and stop worrying about 2.6 for new stuff).

— Donald Stufft

I think the fact that Python 2.6 is past EOL means it's definitely up for consideration. As for the 3% usage, as a trite comparison that's the amount of scientists who deny climate change. So IMO that suggests 2.6 is not used enough to burden PyPA with the maintenance and those who still want to use it can take over maintaining 2.6 compatibility. On Fri, 2 Sep 2016 at 14:06 Donald Stufft wrote:

The packaging tools generally support 2.6+ and 3.(2|3)+ and that's sort of been where they've been at for a while now. I would like to think about what we need to be to start considering Python 2.6 as "too old" to support. In pip we generally follow a usage based deprecation/removal of supported Pythons but we don't have any real guidelines for when something is at a low enough usage to consider it no longer supported and we instead just sort of wait until someone makes a case that it's "low enough".

This issue tends to impact more than just pip, because once pip drops support for something people tend to start dropping it across the entire ecosystem and use pip's no longer supporting it as justification for doing so.

I would like to take a look at Python 2.6 and try and figure out if we're at a point that we can deprecate and drop it, and if not what is such a point.

Looking at pure usage numbers for "modern" versions of pip (6, 7, and 8) for downloading from PyPI I see the usage is ~3% of downloads are via Python 2.6. The only thing lower than Python 2.6 that is still supported is Python 3.3.

Python 2.6 itself has been EOL since 2013-10-29 which is now just about 3 years ago. It's SSL module is not generally secure and requires the use of additional installed modules to get it to be so. I believe the only place to get a Python 2.6 that is "supported" is through the Enterprise-y Linux Distributions like RHEL/CentOS/etc.

Do we think that a ~3% usage of Python 2.6 and being end-of-life'd for ~3 years is enough to start deprecating and dropping 2.6? If not what sort of threshold do we think is enough? It'd be nice to get the albatross of Python 2.6 support off from around our necks but I'm not sure how others feel. Obviously all of the existing versions of all of the tooling will still be fully functional so Python 2.6 users will simply need to not upgrade their tooling to continue to work, *but* it also means that they will be left out of new packaging features (and likewise, people can't rely on them if they still wish to support 2.6).

Thoughts?

— Donald Stufft

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Looking at pure usage numbers for "modern" versions of pip (6, 7, and 8) for downloading from PyPI I see the usage is ~3% of downloads are via Python 2.6.

And a lot of those may be CI systems for packages that still support 2.6.... deprecate away! -CHB On Sat, Sep 3, 2016 at 1:36 PM, Daniel Holth wrote:

It would be convenient to drop 2.6 in wheel too.

On Sat, Sep 3, 2016, 14:14 Brett Cannon wrote:

...

I think the fact that Python 2.6 is past EOL means it's definitely up for consideration. As for the 3% usage, as a trite comparison that's the amount of scientists who deny climate change. So IMO that suggests 2.6 is not used enough to burden PyPA with the maintenance and those who still want to use it can take over maintaining 2.6 compatibility.

On Fri, 2 Sep 2016 at 14:06 Donald Stufft wrote:

...

The packaging tools generally support 2.6+ and 3.(2|3)+ and that's sort of been where they've been at for a while now. I would like to think about what we need to be to start considering Python 2.6 as "too old" to support. In pip we generally follow a usage based deprecation/removal of supported Pythons but we don't have any real guidelines for when something is at a low enough usage to consider it no longer supported and we instead just sort of wait until someone makes a case that it's "low enough".

This issue tends to impact more than just pip, because once pip drops support for something people tend to start dropping it across the entire ecosystem and use pip's no longer supporting it as justification for doing so.

I would like to take a look at Python 2.6 and try and figure out if we're at a point that we can deprecate and drop it, and if not what is such a point.

Looking at pure usage numbers for "modern" versions of pip (6, 7, and 8) for downloading from PyPI I see the usage is ~3% of downloads are via Python 2.6. The only thing lower than Python 2.6 that is still supported is Python 3.3.

Python 2.6 itself has been EOL since 2013-10-29 which is now just about 3 years ago. It's SSL module is not generally secure and requires the use of additional installed modules to get it to be so. I believe the only place to get a Python 2.6 that is "supported" is through the Enterprise-y Linux Distributions like RHEL/CentOS/etc.

Do we think that a ~3% usage of Python 2.6 and being end-of-life'd for ~3 years is enough to start deprecating and dropping 2.6? If not what sort of threshold do we think is enough? It'd be nice to get the albatross of Python 2.6 support off from around our necks but I'm not sure how others feel. Obviously all of the existing versions of all of the tooling will still be fully functional so Python 2.6 users will simply need to not upgrade their tooling to continue to work, *but* it also means that they will be left out of new packaging features (and likewise, people can't rely on them if they still wish to support 2.6).

Thoughts?

— Donald Stufft

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov