Re: [Distutils] When can we kill Python 2.6 support?
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] What is the official position on distutils?
On 2 September 2016 at 19:28, Paul Moore wrote: > On 2 September 2016 at 09:58, Sylvain Corlay wrote: >> My point here was that I don't think that the proposed feature has much to >> do with the concerns that were raised about distutils in general, unless it >> is decided that incremental improvements to the library even backward >> compatible will not be accepted anymore. > > Agreed. I think your feature is only stalled for distutils by the lack > of people sufficiently comfortable with the code to apply it. The > suggestions to add it to setuptools are more in the way of practical > advice on how to make the feature available, rather than expressions > of a policy that "we don't make changes like that in the stdlib". However, one of the other consequences of the status quo is that if Jason's comfortable with a change for setuptools, there's very rarely going to be anyone that will argue with him if he also considers it a suitable addition to the next version of distutils :) Since Jason's primary involvement in distutils-sig & PyPA is as the lead setuptools maintainer, it's easy for folks to be unaware of the fact that he's a distutils maintainer as well. So perhaps that's what we should adopt as the official distutils-sig policy? Any proposed distutils changes should *always* go into setuptools, as that way they're available for all currently supported Python versions, and then it's up to the setuptools project to escalate changes or change proposals for stdlib inclusion when they consider that an appropriate step. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setup_requires: the obvious option(?)
On 2 September 2016 at 13:30, Antony Lee wrote: >> Similarly, it wouldn't astonish me if we eventually see an emergent >> practice of people writing pyproject.toml.in files for complex >> projects, in order to move some particular forms of complexity away >> from build time and towards development time - this would be a similar >> practice to folks using autoconf to generate a project's C Makefile. > > This actually formulates much better than I could have done the reasons why > I dislike PEP518: it's only going to lead to reinventing the wheel (AKA > autoconf, which is a pretty big wheel to reinvent). Unlike autoconf, we don't need to support building arbitrary C/C++ projects - rather, we just want people to have a backend independent way to tell Python-centric toolchains how to invoke their *existing* build system (whether that's autoconf/make, CMake, Scons, waf, Meson, yotta, etc). It's the current *lack* of that ability to readily integrate with existing build tools (whether written in Python or not) that prompts people to reinvent the world. Defining and support PEP 518 means that a possible future workflow for autoconf using projects would be something like: $ ./configure && make pyproject.toml && pip install -e . In that kind of scenario, the "tell Python tools how to build our Python bindings" file becomes just another output of a project's existing build system, which is entirely feasible with a well documented static format, but impractical with the current underspecified and underdocumented setup.py based approach. Cheers, Nick. -- 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?
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 > 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?
> 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?
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?
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
[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
Re: [Distutils] Accepting PEP 527 (reducing the variety of file types supported by PyPI)
Thanks! > On Sep 1, 2016, at 7:19 AM, Nick Coghlan wrote: > > Having reviewed the comments on the PEP 527 thread and the latest > draft of the PEP, I'm now accepting the PEP. This means that: > > * supported sdist types will be reduced to .tar.gz and .zip > * projects will need to choose one or the other for future releases > * supported binary formats will be reduced to bdist_wheel and bdist_egg > > The problem that Maurits van Rees pointed out with ez_setup.py > currently still specifically looking for a zip file and processing it > accordingly can be resolved by setuptools settling on zip as its sdist > publication format (unless/until ez_setup.py is changed to handle > tar.gz). > > Regards, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig — Donald Stufft ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] What is the official position on distutils?
On 2 September 2016 at 09:58, Sylvain Corlay wrote: > My point here was that I don't think that the proposed feature has much to > do with the concerns that were raised about distutils in general, unless it > is decided that incremental improvements to the library even backward > compatible will not be accepted anymore. Agreed. I think your feature is only stalled for distutils by the lack of people sufficiently comfortable with the code to apply it. The suggestions to add it to setuptools are more in the way of practical advice on how to make the feature available, rather than expressions of a policy that "we don't make changes like that in the stdlib". Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] What is the official position on distutils?
Hi Brett, On Mon, Aug 29, 2016 at 9:52 PM, Brett Cannon wrote: > > >> As we discussed earlier, even though it is not a concern with C, checking >> for availability of a compiler flag becomes crucial when building >> extensions with C++ since new flavors of the language emerge every couple >> of years now. It is important to be able to output meaningful error >> messages when the compiler does not support C++[11/14/17] features if they >> are needed for a given extension. This is a new aspect of the landscape in >> this area. >> >> Finally, adding this method is a very straightforward change. `has_flag` >> simply comes aside `has_function` as a method of ccompiler. I don't see a >> more natural place for it. It would be a very weird design decision in my >> opinion to not add it there, and instead to add it to distutils.ccompiler >> by monkeypatching it in setuptools. >> > > Honestly I have no comment on your feature, Sylvain, and I'm sorry your > proposal happens to be the catalyst to this discussion. I'm just trying to > get a general alignment from the PyPA group as the "distutils problem" > comes up and has the same points made every time with no general decision > on how to handle it long-term. > > -Brett > > My point here was that I don't think that the proposed feature has much to do with the concerns that were raised about distutils in general, unless it is decided that incremental improvements to the library even backward compatible will not be accepted anymore. Sylvain ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
