[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MBF for deprecating Python2 usage



On Aug 3, 2017, at 23:23, Scott Kitterman <debian@kitterman.com> wrote:
> 
> Read it.  I remain completely convinced that /usr/bin/python pointing at a python3 version is utterly wrong and a disservice to our users.  Even after we remove python2.7, people will be locally compiling it and using it for a decade.

I think it’s inevitable, and not doing so *eventually* will be a greater disservice.  Sure, not today, maybe not in 2020, but I don’t think we’ll be having this discussion in 2025.  If by then, 5 years after Python 2.7 EOL, users read on SO or some Learning Python site that they can just type ‘python' to get an interactive prompt, but it doesn’t work on Debian, they’ll think Debian is broken, not Python.  So I think it makes sense to consider how the transition will work.

You’re right that folks will still need Python 2 after 2020, and that their best option may be to build it themselves, but I don’t think they’ll be building and installing some old Debian package.  Instead they may build from source, which means they’ll be installing it into /usr/local/bin not /usr/bin, and they’ll have to change their shebang lines anyway.  And there will come a time when even Python 2.7 is unbuildable as toolchains and libraries evolve.  Upstream will stop tracking those changes so even the upstream git repo won’t give you buildable source.  There may be a bunch of third party forks, but I don’t think it’s our responsibility to ensure that Debian aligns with any of those hypotheticals.  Folks needing to stay on Python 2 will probably also just elect to not upgrade their OS, so what we do in future releases won’t matter to them.

Upstream and Debian already install a `python2` alias for `python`, and I think we need to join the chorus that in the future, the way to run Python 2 is via `python2`.  Yes, people will have legacy stuff around for a long time, but it’s better to begin the transition now rather than make a major break years from now.

> Such a change would be actively user hostile.
> 
> When python2.7 goes away, /usr/bin/python should go too.

Maybe in the short term (as Matthias suggests), but I’m not so sure it’s best to disappear /usr/bin/python forever.  /usr/bin/python is not just the common shebang (and we should be actively transitioning to /usr/bin/python2 for that), but it’s also the command line UI for people wanting to learn Python, or just wanting to get an interactive interpreter to play with. There will be a day when, if they get a command not found when typing `python` at a shell prompt, they will wonder why Debian is broken.

I think the transition should roughly be:

* Update policy and tooling so that any scripts that require Python 2 use /usr/bin/python2 in their shebang.

* Educate our users that they should be using `python2` for anything that has not been ported.

* Port as much as possible to Python 3 (eventually, everything maintained in Debian) and /usr/bin/python3 in their shebang.

* Plan for a date at which /usr/bin/python will point to Python 3.  I know that’s the most controversial bit, but I do think that as time goes on and we’re past 2020, it will be the choice that gives our users the best experience.

The discussion on linux-sig is a way to align the entire Python Linux ecosystem to the eventual goal, giving individual distros the leeway they need to time such transitions as they see fit to best serve their users.  I’m hoping more Debian Pythonistas will join that discussion, otherwise the outcome will be heavily weighted toward other Linux distros and Debian may find itself without a voice in the matter.

Cheers,
-Barry


Attachment: signature.asc
Description: Message signed with OpenPGP


Reply to: