On Mon, 19 Nov 2018 at 21:21, Petr Viktorin <encu...@gmail.com> wrote:
> (Wow, am I glad to be legally allowed to talk about this now!)

It does make it much easier than having to dance around what the plans
for RHEL 8 actually were (especially since they weren't the same as
Fedora's plans, so the usual escape hatch didn't work).

> That leaves advantages of "py" to:
> - "py" is shorter (and many people already use it as a custom shortcut!)
> - "py" is consistent with Windows (which is would be great for
> classes/workshops, provided it doesn't make installation harder)
> - plus something about distributions like Anaconda, which I don't know
> much about

The main advantage I see to "py" is that it's deliberately ambiguous
about the exact target version (and can be made to favour Python 3
from the start), whereas "python" has had a much longer history of
referring to some variant of Python 2.x.

It's also the case that if cross-distro Py 2/3 source-compatible
scripts start saying "/usr/bin/py", then it's straightforward to add a
symlink to older systems that resolves to the same target as
/usr/bin/python, even without adding the launcher.

> I'd update the PEP to allow flat-out leaving out "/usr/bin/python". That
> way, users will get the "command not found" error message, which I
> believe to be the most straightforward, easy to spot, easy to fix and
> easy to workaround way to get out of this mess.

My initial reaction was "Doesn't it already say that?", but the answer
is no, it doesn't, since the bullet point about leaving the symlink
out entirely says this:

=============
In controlled environments aimed at expert users, where being explicit
is valued over user experience (for example, in test environments and
package build systems), distributions may choose to not provide the
python command even if python2 is available. (All software in such a
controlled environment must use python3 or python2 rather than python,
which means scripts that deliberately use python need to be modified
for such environments.)
=============

The counterargument to the idea that it's OK to not offer *any*
standard way of exposing a link or launcher that gives you some
arbitrary version of Python available on the system is this open
"Python interpreter autodiscovery" issue for Ansible:
https://github.com/ansible/ansible/issues/45852

At the moment, there's no clear answer as to what to put into the
shebang lines of Python scripts that are cross-distro compatible, and
also source-compatible with Python 2 & Python 3:

- "/usr/bin/python" (and variants like "/usr/bin/env python") will
fail on RHEL/CentOS 8 and any system without Python 2 installed
- "/usr/bin/python3" (and variants) will fail on RHEL/CentOS 7 (unless
py3 has been installed from EPEL)
- "/usr/bin/python2" (and variants) will fail in the same places
"/usr/bin/python" fails, and more besides (since not all distros with
Python 2.x have a python2 symlink)

The other downside of "/usr/bin/python" is the one you mentioned: it's
ambiguous about the script author's intent, since "actively maintained
and Py3 compatible" has the same spelling as "hasn't been touched in
years".

So if we were to amend the PEP to say that "/usr/bin/py" should exist,
and refer to either:

- the Python Launcher for Unix; or
- some version of Python 3.x (or any later Python version); or
- Python 2.7 (if there isn't a more recent version of Python installed)

Then we could also give script shebang line authors clearer guidance
on what to use:

- /usr/bin/python2 for scripts that definitely don't work on Python 3.x
- /usr/bin/python3 for scripts that definitely don't work on Python 2.x
- /usr/bin/python for single source scripts that seek broad
compatibility with older systems running Python 2.x
- /usr/bin/py for single source scripts that seek forward
compatibility with newer systems (and also with older systems that
have been configured to support it)

> P.S. minor semantic nitpick: please don't call the last round of changes
> to PEP 394 "Petr's updates". It was a compromise. My updates would be
> much more radical :)

Heh, fair point - I only called them that since you were the main
driver behind them, and they also marked the point where you became a
co-author on the PEP.

I'll call them the 2018 updates, since I doubt we're going to change
the guidance in the next few weeks.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
_______________________________________________
Linux-sig mailing list -- linux-sig@python.org
To unsubscribe send an email to linux-sig-le...@python.org
https://mail.python.org/mailman3/lists/linux-sig.python.org

Reply via email to