On Friday, August 04, 2017 10:13:00 AM barry@debian.org wrote: > 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. PEP-394 convinced me that upstream wasn't concerned about the same things Debian is concerned about. Even though they did manage to say in the PEP: > The main barrier to a distribution switching the python command from python2 > to python3 isn't breakage within the distribution, but instead breakage of > private third party scripts developed by sysadmins and other users. > Updating the python command to invoke python3 by default indicates that a > distribution is willing to break such scripts with errors that are > potentially quite confusing for users that aren't yet familiar with the > backwards incompatible changes in Python 3. they don't actually consider the implications of that statement. The current discussion only seems to compound the error. I don't see a lot of value in personally expending time on the upstream discussion. If the primary concern is what happens when a user types "python", then can we address that in command-not-found and leave /usr/bin/python out of it? Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.