On 5 August 2017 at 00:27, Barry Warsaw wrote:

On Aug 4, 2017, at 09:22, Nick Coghlan 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@gmail.com | Brisbane, Australia