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