[Distutils] When can we kill Python 2.6 support?

tritium-list at sdamon.com tritium-list at sdamon.com
Fri Sep 2 17:47:18 EDT 2016


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 at python.org] On Behalf Of Donald Stufft
> Sent: Friday, September 2, 2016 5:06 PM
> To: distutils sig <distutils-sig at python.org>
> 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 at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig



More information about the Distutils-SIG mailing list