Re: Ad-hoc Debian Python BoF at PyCon US 2017
On 2017-06-20 16:40:26 +0200 (+0200), Matthias Klose wrote: [...] > another one many openstack packages. [...] Spot checking the source packages in the archive currently, it looks like Thomas already has most of these done. By way of background there, a coordinated effort has been underway for the last several years to get all OpenStack software working with recent Python 3 interpreters. The slowest part of that work involved reaching out to the upstreams of (hundreds of) dependencies not maintained within the OpenStack community and either helping them get working Py3K support, adopting defunct libraries so OpenStack contributors could fix them directly, or in some cases abandoning/replacing dependencies with better-maintained alternatives. This really is an ecosystem-wide effort, as complex Python software doesn't generally run in isolation. I expect the story for other large Python-based applications is very similar to this. Most OpenStack services and libraries are integration-tested upstream to work under Python 3.5 today, but there are still many Python-2.7-only testsuites for them (especially unit testing and some functional tests) which need heavy refitting before the community feels its Py3K support efforts are truly complete. -- Jeremy Stanley signature.asc Description: Digital signature
Re: Ad-hoc Debian Python BoF at PyCon US 2017
On 10.06.2017 05:32, Barry Warsaw wrote: > On Jun 06, 2017, at 10:57 AM, Sandro Tosi wrote: > >> if we plan (and it looks like we do) to support and distribute 2.7 >> with buster, why not support it *properly*? what's the point of >> deprecating python2.7? either we ship it or not, but if we do then >> let's not cripple it by removing python2 modules packages. do yo think >> that just because the module i want to use is not available will make >> realize "oh sh*t, let's migrate this 50k lines of code application to >> py3k so that i can implement this 5-minutes-of-work-funcionality if i >> had the module on py2"? > > So what's the plan for when upstream stops supporting Python 2 in 2020? Given > the pronouncement at Pycon 2017 that maintenance will end at Pycon 2020, we > really need to decide what Debian's official policy will be, and what the > timeline will be to get there. > > If Buster is 2 years in development, that means it will be the last Debian > release before Python 2.7 is EOL'd. Yes, I know it's possible that 2.7 will > get security releases for some time after that, but that's a much reduced > commitment from upstream. > > Once upstream stops supporting 2.7, should we also stop supporting it? That > wouldn't mean that developers on Debian can't use Python 2.7, just that they > will be on their own. I know it sucks for people who can't port to Python 3, > but if a decade or more isn't enough time to switch, then that's really saying > they'll never switch, and how much responsibility does Debian have at that > point? > > Python 2.7 isn't going away today, but 3 years goes by quickly and we need to > decide what our policy will be when the day arrives. There's a big chunk of work getting the python2 dependencies replaced by python3 dependencies. I think we should track these packages with bug reports, so that every source package depending on python2 only, and not providing python3 binary packages has it's own bug report. For now, one big cluster might be packages b-d on python-sphinx instead of python3-sphinx, another one many openstack packages. We can only speculate on the amount of work until we have such a list ... Matthias
Re: Ad-hoc Debian Python BoF at PyCon US 2017
On Friday, June 09, 2017 08:32:38 PM Barry Warsaw wrote: > On Jun 06, 2017, at 10:57 AM, Sandro Tosi wrote: > >if we plan (and it looks like we do) to support and distribute 2.7 > >with buster, why not support it *properly*? what's the point of > >deprecating python2.7? either we ship it or not, but if we do then > >let's not cripple it by removing python2 modules packages. do yo think > >that just because the module i want to use is not available will make > >realize "oh sh*t, let's migrate this 50k lines of code application to > >py3k so that i can implement this 5-minutes-of-work-funcionality if i > >had the module on py2"? > > So what's the plan for when upstream stops supporting Python 2 in 2020? > Given the pronouncement at Pycon 2017 that maintenance will end at Pycon > 2020, we really need to decide what Debian's official policy will be, and > what the timeline will be to get there. > > If Buster is 2 years in development, that means it will be the last Debian > release before Python 2.7 is EOL'd. Yes, I know it's possible that 2.7 will > get security releases for some time after that, but that's a much reduced > commitment from upstream. > > Once upstream stops supporting 2.7, should we also stop supporting it? That > wouldn't mean that developers on Debian can't use Python 2.7, just that > they will be on their own. I know it sucks for people who can't port to > Python 3, but if a decade or more isn't enough time to switch, then that's > really saying they'll never switch, and how much responsibility does Debian > have at that point? > > Python 2.7 isn't going away today, but 3 years goes by quickly and we need > to decide what our policy will be when the day arrives. Regardless of what upstream does, use of python2.7 isn't going to vanish. We've dealt with this before where we get stuck dealing with an old version of something because upstream stops supporting the new before the echosystem has moved on. Gtk 1.2 and Qt3 come to mind as relatively recent examples. Similarly, we are just a few days away from releasing Stretch with Qt4 even though it's been years since upstream supported it. I think the right thing to do here is look at applications that have not migrated to python3 and see what can be done to facilitate them going to python3. The fewer depends that pulls in python2.7 based packages, the fewer people will need it and the easier it will be to eventually make progress with removal. I was just reading recently that python2.7 has become very popular in the scientific community precisely because it isn't getting new features. It makes reproducibility of experiments much easier. Until the python2.7 maintainer indicates a plan to remove it, I think we continue supporting it in the rest of the echosystem in a reasonable way. So far, every time I've tried to do only the python3 version of something, I always have gotten asked for the python version too. I don't think we're there yet (or even close) no python3 only. Scott K
Re: Ad-hoc Debian Python BoF at PyCon US 2017
On Jun 06, 2017, at 10:57 AM, Sandro Tosi wrote: >if we plan (and it looks like we do) to support and distribute 2.7 >with buster, why not support it *properly*? what's the point of >deprecating python2.7? either we ship it or not, but if we do then >let's not cripple it by removing python2 modules packages. do yo think >that just because the module i want to use is not available will make >realize "oh sh*t, let's migrate this 50k lines of code application to >py3k so that i can implement this 5-minutes-of-work-funcionality if i >had the module on py2"? So what's the plan for when upstream stops supporting Python 2 in 2020? Given the pronouncement at Pycon 2017 that maintenance will end at Pycon 2020, we really need to decide what Debian's official policy will be, and what the timeline will be to get there. If Buster is 2 years in development, that means it will be the last Debian release before Python 2.7 is EOL'd. Yes, I know it's possible that 2.7 will get security releases for some time after that, but that's a much reduced commitment from upstream. Once upstream stops supporting 2.7, should we also stop supporting it? That wouldn't mean that developers on Debian can't use Python 2.7, just that they will be on their own. I know it sucks for people who can't port to Python 3, but if a decade or more isn't enough time to switch, then that's really saying they'll never switch, and how much responsibility does Debian have at that point? Python 2.7 isn't going away today, but 3 years goes by quickly and we need to decide what our policy will be when the day arrives. -Barry
Re: Ad-hoc Debian Python BoF at PyCon US 2017
> == Deprecate Python 2 == > > Lintian checks for python 2 only packages > Lintian checks for /usr/bin/python2? shebangs please dont (as in "favor python3" but dont actively discourage python2 development/packaging), see below > == python 2.7s future == > > Buster *may* be the last Debian release with Python 2.x. Maybe drop it into > unstable-only, after that? > > Stefano is sceptical :P > > Fedora expects to be shipping 2.7 for a long while still. if we plan (and it looks like we do) to support and distribute 2.7 with buster, why not support it *properly*? what's the point of deprecating python2.7? either we ship it or not, but if we do then let's not cripple it by removing python2 modules packages. do yo think that just because the module i want to use is not available will make realize "oh sh*t, let's migrate this 50k lines of code application to py3k so that i can implement this 5-minutes-of-work-funcionality if i had the module on py2"? the lintian check *currently* in place (discouraging to introduce py2 packages) is making more harm than good: it's easy to add a py2 package when you're packaging a new source module, it's a lot harder (and impossible when you need that module in stable, unless you what to use backports) once the package is already in the archive. I'm happy that you work in a place where there are so few legacy projects still on python2, and that you have some much time to migrate them to py3k in a timely fashion; on the contrary, in many other businesses, this is a long process, often requiring re-engineering and a long trial-and-error phase to replace existing working py2 code with py3k. Even more often, you just add functionalities to the old code and move on to the next task: simply not providing py2 modules will only frustrate our users (for example, me) and will force them to... what's the solution here for a stable release? pip install the missing deps? wow sorry, just my 2c -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
