[Linux-SIG] Revisit of PEP 394 -- The "python" Command on Unix-Like Systems

[Nick Coghlan]

On 5 August 2017 at 00:27, Barry Warsaw <barry at python.org> wrote:
> On Aug 4, 2017, at 09:22, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> Where the idea of a "try to compile it as Py3 to see if that works,
>> but report an error anyway" script then comes in is as a potentially
>> better failure UX than the default "interpreter not found" from the
>> operating system's shebang processing.
>
> This makes me uncomfortable, because I think there will be cases, especially with smaller, one-off scripts, where compilation succeeds but where the code still has subtle failure modes at run time.  And for larger applications, doing a pre-compile isn’t going to help start up time.  Plus, you have to disable pyc generation or ensure that if the compilation fails, all the artifacts of that are cleaned up.  It seems like a lot of complexity with plenty of opportunities for failure and false matches.
>
> The Zen of Python just begs to be quoted. :)

A colleague also pointed out that it's much easier to *add* this kind
of heuristic based advice later than it is to take it away. So
consider me convinced that while a custom error message may be
appropriate, that message should be independent of the specific script
supplied (however, it may still take into account which Python stacks
are already installed on the system, and should *definitely* take into
account which stacks are available for installation on that particular
distro)

> Maybe muxing won’t be a useful technique in practice, but in that case I think a short term “no /usr/bin/python” is a better transition step.

The only reason I moved away from that stance is because the shebang
handler doesn't give very good error messages when it doesn't find the
specified interpreter. However, it's the same idea in principle (i.e.
an unqualified shebang reference will fail by default, and then it's
up to the system administrator to decide whether it should be
reconfigured to do something else).

>  I agree that we should be actively recommending Python 2-only scripts be shebanged to /usr/bin/python2.  When Python 2.7 is EOL’d, one distro release without /usr/bin/python would be a pretty clear indication that you need to fix your scripts, but PEP 394 should give distros the leeway to choose their own timing on that.

Yeah, Fedora has effectively been in this state since F23: by default,
/usr/bin/python just fails, since the Python 2 stack is missing by
default.

The state I'm now aiming to get to is to have that failure offer a few
distinct options:

1. Change nothing, "/usr/bin/python" and "python" outside a venv of
some kind just fails
2. Change the shebang line to use the installed-by-default Py3 stack
3. Reconfigure the system to always use the Py3 stack by default
4. Install the Py2 stack, change the shebang line to use it explicitly
5. Install the Py2 stack, reconfigure the system to use it by default

Right now, the available options in F26 are the first two and the last
two, so the main thing I'm trying to figure out is how we can feasibly
offer the middle one as an opt-in admin-controlled feature.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia