Python support policy

Eric S. Raymond esr at thyrsus.com
Thu Sep 3 00:51:45 UTC 2020


Richard Laager via devel <devel at ntpsec.org>:
> 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.

I'm in favor of this simple, brute-force approach.

If nobody comes up with a good argument for retaining Python 2
support, I will ask Mark to include in the release notes that this
is our *last* release with Python 2 support.  Then we'll rip out the
Python 2 code paths before the next one.

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

I don't want to go down this road.  I have ugly memories associated
with a smiliar hack in gpsd, long ago.

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

Yes.  To the best of my knowledge every current Unix-like thing
does right with python3 in the shebang line.  That makes hacking those
shebangs as unnecessary as it would be hazardous.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


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


More information about the devel mailing list