[Distutils] When can we kill Python 2.6 support?

[Chris Barker]

> 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 <dholth at gmail.com> wrote:

> It would be convenient to drop 2.6 in wheel too.
>
> On Sat, Sep 3, 2016, 14:14 Brett Cannon <brett at python.org> 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 <donald at stufft.io> 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 at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160906/b1b2bcd2/attachment.html>