Python support policy

[Richard Laager]

On 9/5/20 2:19 PM, Gary E. Miller via devel wrote:
> And yet, Gentoo, and others still ship 2.7.  And end users still use it.

This is not a discussion about whether Gentoo should drop Python 2.7.
It's not a discussion about whether users should stop using Python 2
entirely. Perhaps we can intuit each other's views on those topics, but
that's not what is being discussed here.

NTPsec currently supports: Python 2 >= 2.6 or Python 3 >= 3.3

There are four possible sets:

A) !(Python 2 >= 2.6) and !(Python 3 >= 3.3).
   That is, it has neither version of Python at all or neither meets the
   minimum version.
B) (Python 2 >= 2.6) and !(Python 3 >= 3.3).
   That is, either it has no Python 3 or its Python 3 is < 3.3.
C) (Python 2 >= 2.6) and Python 3 >= 3.3.
   That is, it has both Python 2 and Python 3 in versions that meet
   NTPsec's minimums.
D) !(Python 2 >= 2.6) and Python 3 >= 3.3.
   That is, it has an acceptable Python 3, but no acceptable Python 2.


Category A is irrelevant, as NTPsec already does not run there.


Category B is the relevant case to the main purpose of this thread: the
proposal to drop Python 2 support.

If a system is in category B because that particular system doesn't have
Python 3 installed, but the distro ships Python 3 >= 3.3, the solution
is simple: install Python 3. That doesn't change anything with their
Python 2 environment. If the user has critical Python 2 code, it stays
working just as it was.

If a system is in category B because the distro does not ship Python 3
>= 3.3, then Eric's proposal to drop Python 2 support means dropping
support for that distro. An example of that is RHEL 6. Because RedHat's
support lifecycles are generally longer than other distros' support
lifecycles, it is likely that RHEL 6 is the last example of such a
distro. RHEL 6's security support ends in November. Once that happens,
the affected population are users who both want to run the latest NTPsec
and are running a distro version that is no longer receiving security
updates. Why is that a scenario that NTPsec needs to support? Doubly so
given NTPsec's otherwise aggressive stance on removing old stuff in the
name of maintainability and security?


Last year, the current release of essentially every distro was likely in
category C. Users could use NTPsec with either Python 2 or Python 3 (but
only whichever version was providing `python`; see below).


Now that Python 2 has been end-of-lifed upstream, category D is likely
to expand. In this category, users must use NTPsec with Python 3.
Unfortunately, building/using NTPsec on a Python 3-only system without a
`python` symlink to Python 3 (e.g. Ubuntu 20.04) currently does not work
at all.

  The minor problem is that waf has a `python` shebang. If the distro
  does not ship `python` (as is the case on Ubuntu 20.04 out of the
  box), then `./waf` will not run.

    Whether a Python 3-only system should symlink `python` to `python3`
    is debatable.  Both options have pros and cons.  In the case of
    Ubuntu, one option is the default (no `python`) and the other is
    available by admin choice (by installing the python-is-python3
    package).

  The lack of `python` can be trivially worked around with `python3 waf`
  if the user knows to do so. (We should update the INSTALL docs with a
  note on that once the bigger problem is resolved.)

  The bigger problem is that the installed scripts have a hardcoded
  shebang of `/usr/bin/env python` so none of them work. That can be
  addressed by subst'ing the shebangs as in !1166:
  https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1166

-- 
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/20200905/5b0a1f9b/attachment.bin>