Path: csiph.com!feeder.erje.net!2.eu.feeder.erje.net!news2.arglkargh.de!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From: Geoffrey Thomas <geofft@ldpreload.com>
Newsgroups: linux.debian.maint.python
Subject: Re: MBF for deprecating Python2 usage
Date: Tue, 08 Aug 2017 00:50:02 +0200
Message-ID: <ubZ0u-6St-17@gated-at.bofh.it>
References: <uawjU-5YP-3@gated-at.bofh.it> <uaBtf-1rM-9@gated-at.bofh.it> <uaLCi-867-15@gated-at.bofh.it> <uaS13-3Oj-19@gated-at.bofh.it>
Old-Return-Path: <geofft@ldpreload.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Approved: robomod@news.nic.it
Lines: 42
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.python:9726

On Fri, 4 Aug 2017, Scott Kitterman wrote:

> 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?

Debian doesn't ship command-not-found by default. One other approach here 
would be to have /usr/bin/python exec python3 if it's run interactively -- 
that is, if isatty(0) -- and print an error message and exit otherwise. 
I don't think it is too bad to print an error message instead of failing 
the exec, since that's equivalent to what happens if you're missing a 
shared library or something: the exec succeeds, but the dynamic loader 
prints an error and exits nonzero.

Ship this /usr/bin/python with python3-minimal, and have the 
python-minimal package divert it and replace it with the current 
/usr/bin/python (a symlink to python2.7). This way we can build systems 
with Python 3 only that behave reasonably, but also allow doing `apt-get 
install python` to cause /usr/bin/python to start working again.


However, I feel like another reason to care about /usr/bin/python is so 
that sysadmins responsible for multiple platforms can continue writing 
#!/usr/bin/python (or #!/usr/bin/env python) scripts and use the same 
script on all their machines. If I can't do this and need 
platform-specific scripts, I might as well use some other language or ship 
compiled binaries. Keeping Python viable for this use case is a large part 
of why I originally proposed pythonmux: I can write scripts that declare 
that they're polyglot Python 2/3 and work on both Python 2-only and Python 
3-only systems, but a Python 2 script using #!/usr/bin/python will give me 
an error (as it should!) if there's no Python 2 installed on the machine.

Last time I checked (2015), entirely reasonable versions of RHEL and macOS 
both shipped only Python 2 and not Python 3. Is it likely to be the case 
that all UNIXy OSes within security support in 2019 or 2020 will have a 
/usr/bin/python3 (preferably 3.3+)? If so, that's a viable option. I just 
want my best migration path from #!/usr/bin/python to not involve 
rewriting my scripts in Go.

-- 
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com