Re: [Distutils] When can we kill Python 2.6 support?

[Barry Warsaw]

On Sep 02, 2016, at 05:05 PM, Donald Stufft wrote:

>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?

Yes!

Cheers,
-Barry


pgpCalDLuc3vp.pgp
Description: OpenPGP digital signature
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [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  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(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] When can we kill Python 2.6 support?

[Daniel Holth]

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

Re: [Distutils] When can we kill Python 2.6 support?

[Brett Cannon]

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

Re: [Distutils] When can we kill Python 2.6 support?

[Nick Coghlan]

On 3 September 2016 at 07:47,   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.

It won't (or at least shouldn't) be out of the blue:
http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
;)

From a specifically Red Hat perspective, it's probably worth
mentioning that Red Hat doesn't commercially support pip in
conjunction with any version of Python 2.6 - we only provide a Red Hat
supported pip for the Software Collections runtimes, and the lowest
version of Python we provide as an SCL is 2.7.

My "Developing in Python on Red Hat Platforms" talk with Graham
Dumpleton in the DevNation/Red Hat Summit cross-over track this year
[1] was also basically telling people "Stop using the system Python to
run your own stuff, especially on RHEL 6", and advocating the use of
higher level alternatives like OpenShift v3, Software Collections, and
Ansible instead (depending on whether you were writing network
services, client applications, or system administration scripts).

So if pip 9.0 were to deprecate Python 2.6 support, I think that would
be an entirely reasonable decision for PyPA to make from an upstream
maintainability perspective - if folks genuinely want long term
infrastructure software maintenance for Python projects, they need to
be pestering commercial redistributors about funding that, rather than
assuming volunteers will always deliver it for free even when they're
running newer Python versions themselves.

The deprecation cycle would then mainly be about giving pip's
*community* users a heads up that CI testing against Python 2.6 was
being dropped, with Python 2.7+ likely becoming a requirement in a
future version.

Cheers,
Nick.

[1] 
http://www.slideshare.net/ncoghlan_dev/developing-in-python-on-red-hat-platforms-devnation-2016

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] When can we kill Python 2.6 support?

[tritium-list]

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

> -Original Message-
> From: Donald Stufft [mailto:don...@stufft.io]
> Sent: Friday, September 2, 2016 6:18 PM
> To: tritium-l...@sdamon.com
> Cc: distutils sig <distutils-sig@python.org>
> Subject: Re: [Distutils] When can we kill Python 2.6 support?
> 
> 
> > On Sep 2, 2016, at 5:47 PM, tritium-l...@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
> 
> 


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

Re: [Distutils] When can we kill Python 2.6 support?

[Donald Stufft]

> On Sep 2, 2016, at 5:47 PM, tritium-l...@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



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

Re: [Distutils] When can we kill Python 2.6 support?

[tritium-list]

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@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

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

Re: [Distutils] When can we kill Python 2.6 support?

[David Mertz]

Kill it with fire!

On Sep 2, 2016 2:06 PM, "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