On 3 August 2017 at 01:49, Barry Warsaw <ba...@python.org> wrote:
> Now, a system administrator managing a suite of shebanged third party
> scripts for their organization should be able to change the mux'd default.
> As much as I hate introducing a configuration file, I think that's going to
> be appropriate here. That would allow:
>
> * A system admin to select the system-wide default Python version, assuming
> the platform provides the option of different versions;
>
> * Individual scripts can make their own selection, overriding the system
> defaults;
>
> * Individual users can override the script selection by setting an
> environment variable.
>
> * A user at the command line could also provide a switch to make the
> selection.
The reason I don't think the "pyversion" comment will help in practice
is that there's only 3 compatibility states that we really care about
for this particular problem, and they're all already expressible
directly in the shebang line regardless of whether the target system
uses pythonmux or not:
* Python 2 only ("python2")
* Python 3 only ("python3")
* hybrid subset ("python")
As a result, the key remaining UX problem is how server admins want
scripts nominally in the hybrid subset to be handled, where there are
three main options that make sense (depending on the state of their
infrastructure, the amount of legacy Py2 scripts they still need to
cope with, and their level of confidence in debugging
"Py2-code-on-Py3" exceptions):
- always Py2 (status quo)
- always Py3 (desired future state)
- just let it fail and require that the Python version to use be
specified at runtime based on out-of-band compatibility info, instead
of relying on the shebang line (transition state)
If a particular script genuinely needs 2.x, then python2 is ubiquitous
enough now to just change the shebang line. If it genuinely needs Py3,
then it will typically *already* have "python3" in the shebang line,
due to "python" meaning Python 2.x by default on most current systems.
That means the required system level settings are still simple enough
to be handled as a symlink, rather than needing to be a config file.
Adding pythonmux and pyversion into the mix thus doesn't gain you much
except additional maintenance complexity, since people still can't
rely on it: there will still be too many systems where "python" will
either be with missing entirely or an unqualified reference to Py2 or
Py3. A new comment format unfortunately also doesn't even help
distinguish between "legacy Py2 only script" and "script that has been
updated to the hybrid subset of 2 & 3", since there are plenty of the
latter already in existence that don't have, and probably won't gain,
any new special comment syntax.
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.
Cheers,
Nick.
P.S. All that said, I'm not necessarily opposed to adding some form of
"Tested against" magic comment to Python scripts in order to help
distros provide a better UX when a only-tested-on-a-fast-moving distro
script fails on an older LTS distro (and the author of the script
remembered to provide the new embedded metadata). I just don't think
we should couple that discussion to the discussion of what we want to
do to provide a better UX when handling scripts that *lack* such a
marker *and* use an absolute path to an unqualified "python" command
in their shebang line.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Linux-sig mailing list
Linux-sig@python.org
https://mail.python.org/mailman/listinfo/linux-sig
