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
Reply to: