What's the status of the work on shebangs and/or ctype?

[Richard Laager]

I touched up the the shebang MR !1166 just now.

It consists of three commits:

----

The first commit is:

    Subst installed Python shebangs

    This adds a ./waf configure --pyshebang option.  This is used as the
    shebang in the installed Python scripts.  (Scripts that are not
    installed by waf have been left alone.)

    The default is still "/usr/bin/env python", so this is a no-op by
    default.

There are various Python issues open. There are _at least_ these three:
1. Switch the Python module to use FFI?
2. Drop Python 2 entirely?
3. Make Python 3 the default (e.g. for waf)?

Under any combination of those, I think the above commit is desirable.
The closest we get to not needing it is if we want to entirely drop
Python 2 support. In such a case, we would use `/usr/bin/env python3` by
default. Even in that case, it is desirable to me to have it
customizable, as the Debian package needs `/usr/bin/python3` (`env` is
prohibited by Debian Python Policy). Granted, NTPsec upstream could just
tell me to use sed, and that would work. So this isn't a clear _need_,
but a nice-to-have _want_.

One of the problems here is that we have a variety of interlocking
issues. It would be nice to make some forward progress by pruning the
decision tree. I'd like to merge at least that first commit now, even if
there is more discussion needed on the second.

----

The second commit is:

    Automatically detect the Python shebang

    The Python shebang is detected with the following priority:

    1. If the user explicitly specifies --pyshebang, use that.
    2. If the user explicitly specifies PYTHON or --python, use that.
       If it is not an absolute path, run under `/usr/bin/env`.
    3. If the user ran waf under an explicit interpreter (e.g.
       `python3 waf` is a common idiom), use sys.executable, which is
       the interpreter's idea of its own name.  (There is no way to get
       the original interpreter as typed, as sys.argv[0] is still "waf",
       not e.g. "python3".)
    4. Use `/usr/bin/env python` as before.

    Examples:

    These use /usr/bin/env python:
      ./waf configure
      ./waf configure --python=python
      PYTHON=python ./waf configure

    These use /usr/bin/env python3:
      PYTHON=python3 ./waf configure
      ./waf configure --python=python3
      PYTHON="/usr/bin/env python3" ./waf configure

    These use /usr/bin/python3:
      PYTHON=/usr/bin/python3 ./waf configure
      ./waf configure --python=/usr/bin/python3

    This uses Python's sys.executable for python3 which might be
    /usr/bin/python3 or something else, depending on the system:
      python3 waf configure

    Fixes #667

waf (as in upstream waf, not the NTPsec configuration of it) has a stock
option named --python. If users choose to use that, they can easily get
nonsensical results. For example, prior to this commit, if they use
`./waf configure --python=python3` they would still get a shebang of
`/usr/bin/env python`; if `python` is Python 2 (as it is typically on
Debian and RedHat systems), this breaks. That's dumb. Let's fix that by
merging this commit.

If we drop Python 2 support, a lot of the practical reason for this
commit goes away. But in principle, I still think we should provide
working results for people who use waf's --python option. Maybe they're
using a custom Python in /usr/local or ~ or something.

If we change the default from `/usr/bin/env python` to `/usr/bin/env
python3` but _keep_ Python 2 support, this commit is still valuable
because we have the same problem in reverse. That is, people who need
Python 2 should be able to run e.g. `python waf configure` or `python2
waf configure` and get a working result.

----

The third commit is:

    Document how to run waf without `python`

    Some distros no longer ship a `python`.  Ubuntu 20.04 and CentOS 8
    are examples.

This is a simple doc fix that adds:

   If you are running on a distro with no `python` executable, you will
   need to run waf as `python3 waf` rather than `./waf`.

That should not be controversial. It depends on the second commit,
though. If we cannot merge the second commit, then we could say this
instead:

   If you are running on a distro with no `python` executable, `./waf`
   will not work. Instead, use:

     python3 waf configure --pyshebang="/usr/bin/env python3"
     python3 waf build
     python3 waf install

-- 
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/20200917/643909e3/attachment.bin>