Python support policy

[Richard Laager]

Let me start over now that I've reviewed the specifics of the NTPsec
scripts and build system again:

We are currently using "#!/usr/bin/env python" in all the scripts, and
waf uses the same. The minimum to do to drop Python 2 is:

1. Change waf's shebang:
     -#!/usr/bin/env python
     +#!/usr/bin/env python3

   That way, on systems where python is Python 2, waf will get Python 3.
   While there is a lot of baggage around whether "python" is Python 2,
   Python 3, or neither (i.e. doesn't exist), python3 existing is pretty
   universal. [Discussion 1]

2. Change the other scripts the same way.

3. Update the docs and CI accordingly.


An additional improvement (which we could do separately from the Python
2 vs Python 3 discussion) would be to allow the user to customize the
shebang with a build flag. It turns out we already have `./waf configure
--python` which defaults to sys.executable. This is stock waf behavior.
We are already running the Python scripts through subst. We just aren't
doing the last piece of using @PYTHON@ as the shebang. So we could either:

  A. Change the Python shebangs to:
       #!@PYTHON@
     I just tested that on one and it works as expected.
  B. Leave them as "/usr/bin/env python3" and write a custom subst
     function to replace that (and do the usual subst).

Option A is trivial. I could have that patch done in 10 minutes.

Option B is a little bit more work, but keeps the scripts directly
executable from the source tree, which could be helpful for development.
(The other substitutions aren't typically critical, as they are things
like @NTPSEC_VERSION_EXTENDED at .) Is this something people care about?


Discussion 1:

   Python 3 is "supposed" to be available via an executable or symlink
   named "python3".

   That's supported in black and white by PEP 394, which says:

    "We expect Unix-like software distributions...to install the python2
     command into the default path whenever a version of the Python 2
     interpreter is installed, and the same for python3 and the Python 3
     interpreter."

    "When invoked, python2 should run some version of the Python 2
     interpreter, and python3 should run some version of the Python 3
     interpreter."

   What is "supposed" to be the case is mostly moot anyway, so I'm not
   going to argue about this further. What matters is the real world.


   Python 3 is, in practice, actually available via an executable or
   symlink named "python3".

   python3 exists on Debian and derivatives as well as RedHat and
   derivatives. Ubuntu 20.04 optionally allows python to point to
   python3, but always still has python3. I use Debian, Ubuntu, and
   RedHat, so I have personal knowledge here.

   Some examples:

   Debian 10 (current stable):
    $ ls -la `which python3`
    lrwxrwxrwx 1 root root 9 Mar 26  2019 /usr/bin/python3 -> python3.7

   Debian unstable:
    $ ls -la `which python3`
    lrwxrwxrwx 1 root root 9 Apr  7 05:43 /usr/bin/python3 -> python3.8

   Ubuntu 18.04 (previous LTS):
    $ ls -la `which python3`
    lrwxrwxrwx 1 root root 9 Oct 25  2018 /usr/bin/python3 -> python3.6

   Ubuntu 20.04 (current release):
    $ ls -la `which python3`
    lrwxrwxrwx 1 root root 9 Mar 13 07:20 /usr/bin/python3 -> python3.8

   CentOS 7:
    $ ls -la `which python3`
    lrwxrwxrwx. 1 root root 9 Sep  2 17:20 /usr/bin/python3 -> python3.6

   Arch's python is python3, but also still has python3:
    https://www.archlinux.org/packages/extra/x86_64/python/

   OpenSUSE uses python3. Here is some random guy showing it:
    https://youtu.be/T08_SO0YAjA?t=57

   I checked with a Gentoo user I know and they confirmed that their
   system also has a "python3".


   Note carefully that I am not talking about what shebang distro policy
   says should be used for distro packages of NTPsec. Distro packages
   can, should, and are likely required to change the shebang from a
   general one like "/usr/bin/env python3" to something specific to the
   distro environment.

   Debian says to do this:

https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter_loc

   Gentoo says to do this:

https://dev.gentoo.org/~mgorny/python-guide/helper.html#fixing-shebangs-on-installed-scripts

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200902/62f951a4/attachment.bin>