What should Debian do about Python 2? (was Re: next version of csvkit)
On Apr 01, 2017, at 05:12 PM, Ghislain Vaillant wrote: >Pasting the relevant quotes below: > >"The 2.x series of Python is due for deprecation and will not be maintained >past 2020 so it is recommended that Python 2 modules are not packaged unless >necessary." It's true that upstream will almost certainly end bug fix support for Python 2.7 (and thus the 2.x series) in 2020, with the exact date still TBD. It's not unlikely that source-only security fixes will continue upstream for some indeterminate time after that, but it depends on quite a few factors, not the least of which is core developers and an RM still interested in working on Python 2. Keep in mind that 2.7 will be *10 years old* at that point! Distributions with long term support releases will also be continuing to support Python 2.7 in some capacity after that. Ubuntu's 16.04 LTS release will live until 2021. Other distros may have longer commitments. I am hoping that in Ubuntu, we will be able to demote Python 2.7 for the 18.04 LTS release so that we won't be committed to supporting it until 2023, but we'll see about that. As for Debian, I do think we need to plan on how and when we're going to downgrade our commitment to Python 2. Yes, there will probably be Python 2 code bases for effectively forever, but that doesn't necessarily mean Debian's commitment to it also has to be open ended. It's not an easy decision or transition, but I think it's inevitable. Already we are seeing upstream library authors beginning to drop Python 2 support, so I suspect at some point we may have to split source packages if we think we still want to maintain Python 2 and 3 for some packages. >"The idea is to basically stop uploading new Python 2 only libraries, >port things on the critical path, and swap leaf packages to Python 3." I think we should be very strict about leaf packages. If they support Python 3 we should not allow them to enter Debian as Python 2 applications, and all new uploads of leaf applications should use Python 3 if at all possible. For libraries that already support 2 and 3, I don't think we necessarily need to actively drop Python 2 yet. We have great tools, so it's usually just as easy to continue supporting both. I'm on the fence for new library packages, but I suppose if it's also just as easy to support both, we might as well go through NEW for both, since it's easier to drop binary packages than add them. I think we should strongly discourage (or even reject?) new Python 2-only library packages, and I think that's the scenario that the lintian tag is trying to support. >csvkit definitely qualifies as such leaf package, since it is a >collection of command-line tools, not a Python library. Does it support Python 3? If so, then why not make them Python 3 applications? Debian's long term plans for Python 2 would be a great topic to discuss at Debconf. -Barry
Re: What should Debian do about Python 2? (was Re: next version of csvkit)
Barry Warsaw writes: > For libraries that already support 2 and 3, I don't think we necessarily need > to actively drop Python 2 yet. We have great tools, so it's usually just as > easy to continue supporting both. I'm on the fence for new library packages, > but I suppose if it's also just as easy to support both, we might as well go > through NEW for both, since it's easier to drop binary packages than add them. It is perhaps worth noting that Django 2.0 is due to be released in December: https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ It will require Python >= 3.5 - that is no support for Python 2.x. https://docs.djangoproject.com/en/dev/releases/2.0/ -- Brian May
Re: Fwd: next version of csvkit
Vincent Bernat writes: > On the current subject, I also agree we should not drop prematurely > packages targeted to Python 2. It is likely the support will be extended > past 2020, at least by distributions with a 10-year support. RHEL 7 will be supported until 2024. https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_7 I seem to recall RH had a commitment to support Python 2.7 until 2030, but I can't find that now. However, just because some random distribution is supporting Python 2 past 2020, doesn't mean we have any obligation to do so. Also "we support Python 2.7" doesn't mean "support Python 2.7 in unstable." It is possible that we will continue supporting Stretch, post 2020 as a LTS release. https://wiki.debian.org/LTS Providing *full* Python 2.7 support in unstable is likely to prove to be harder and harder when various upstreams start dropping Python 2.7 support, starting with Django this December. e.g. When Django drops support, and we upload that version to unstable, suddenly everything that depends on Django will also fail to work under Python 2.7. https://docs.djangoproject.com/en/dev/releases/2.0/ If Django 2.0 is released on schedule, I would like to see it in Buster - assuming our release cycle remains every 2 years, that will make it early 2019. I would suggest that Buster have Python 2.7, however we only support 3rd party libraries where it is practical to do so. Any library that has dropped Python 2.7 support upstream, is not practical for us to support in Python2. Anything that depends on such a package (directly or indirectly) also is not practical for us to support. -- Brian May
Re: What should Debian do about Python 2? (was Re: next version of csvkit)
Brian May writes: > It is perhaps worth noting that Django 2.0 is due to be released in > December: > > https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ Yes. More directly, Django 1.11 is planned to be the final Python-2-compatible release. From the above URL: As a final heads up, Django 1.11 is likely to be the last version to support Python 2.7 as it will be supported until the end of Python 2 upstream support in 2020. -- \ “It's my belief we developed language because of our deep inner | `\ need to complain.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney
Re: Fwd: next version of csvkit
On 2017-04-04 08:21, Brian May wrote: > I would suggest that Buster have Python 2.7, however we only support 3rd > party libraries where it is practical to do so. Any library that has > dropped Python 2.7 support upstream, is not practical for us to support > in Python2. Anything that depends on such a package (directly or > indirectly) also is not practical for us to support. I just noticed that Ubuntu plan to drop Python 2.7 completely - from default installs at least - for the 18.04 release: "Plans for 18.04 LTS Overarching goals include: Python 3 only on the default installs for desktop, server, touch, snappy images. (Some may already be there.) Python 3.6 transition" https://wiki.ubuntu.com/Python Trying to find out what the situation will be for the 17.04 release, not finding much yet however.
Re: next version of csvkit
On Apr 04, 2017, at 09:49 AM, Brian May wrote: > I just noticed that Ubuntu plan to drop Python 2.7 completely - from >default installs at least - for the 18.04 release: That's not the same as dropping Python 2.7 from the archive, which we're no where near close to doing. It's really just an extension of what I mentioned before. Specifically, any leaf packages that go on the default installs should be Python 3 only, and thus by reverse dependency, only python3-* library packages would go on images. Note that Ubuntu is almost already there, but Samba (which afaik is still not ported to Python 3) is keeping it on the desktop image. Nothing is different for 17.04. Depending on how the 3.6 transition goes for 17.10, I'd like to explore options for demoting Python 2.7 to universe so we don't need to make LTS guarantees for it for 18.04, but that will depend on the technical details and available resources (e.g. my time ;). I don't foresee any possibility of dropping it from the archive for 18.04. Cheers, -Barry
Re: Fwd: next version of csvkit
Brian May writes: > I just noticed that Ubuntu plan to drop Python 2.7 completely - from > default installs at least That's a pretty important modifier! Ubuntu does not yet plan to drop Python 2.7 completely. Rather, the current plan is to ensure no *dependencies on* Python 2.7 in the default installs. It's the reverse dependencies that are being targeted; not Python 2.7 itself. So, similar to what we Debian Python folk are striving to do: no plan to drop Python 2.7, instead working on the reverse dependencies. -- \“Absurdity, n. A statement or belief manifestly inconsistent | `\with one's own opinion.” —Ambrose Bierce, _The Devil's | _o__)Dictionary_, 1906 | Ben Finney
