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

Thu Sep 17 16:54:57 UTC 2020

Yo Richard!

I agree with the first of 4 goals of the MR.

Goal 2 is munging explicit user input in ways that disallow
PEP conformance and generality.

Goal 3 breaks Gentoo and violates the PEP.

The fallback, goal 4, is "/usr/bin/env python".  Does anyone
object to making that "/usr/bin/env python3"?

Rather than go around and around, how about a simple MR that only
implements goals 1 and 4?

The proble

On Thu, 17 Sep 2020 02:46:23 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> 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
> 

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200917/1be9ab50/attachment.bin>