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@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
g...@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
pgpEdNitmFzji.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
