On 2025-02-01 16:33, Fred Wright via devel wrote:
On Fri, 31 Jan 2025, Richard Laager via devel wrote:
Python 2 has been upstream EOL for 5 years. The burden here should be
on people who want to keep supporting it, not on people who want to
drop support for it.
The burden shouldn't be on people to keep adapting to new brokenness,
rather than using what already works, or newer versions from people who
actually think that breaking things is a bad idea (unlike the python.org
folks).
If you don't like a dependency, or don't trust the authors of it, then
use something else.
On 2025-01-30 18:19, Fred Wright via devel wrote:
It's not about whether Python 3 is available, but about whether it's
usable for whatever code they may have that uses ntpsec's Python
modules.
What "code [do] they...have that uses ntpsec's Python modules"?
I don't think I have seen any third-party code using NTPsec's Python
modules, only the built-in utilities. In Debian, I only ship a Python
3 version of the "ntp" module from NTPsec and I've never heard from
anyone that this was a problem. I realize lack of complaints doesn't
prove anything, but it's anecdotal evidence at least.
You're assuming that all Python code on the planet is published. I
personally have a bunch of unpublished Python code which I've never
reworked to work with Python 3. I don't write any *new* Python code
that doesn't work with Python 3, but fixing existing code is real work.
I'm suggesting (and asking for counterexamples) that there is no
third-party code that uses NTPsec's "ntp" module with Python 2. There is
quite possibly no third-party code using that module at all.
I'm certainly not assuming that all code is published. There could be
private code out there. But has anyone seen or heard of any? (I'm asking
about code that uses the NTPsec Python library; obviously I know people
have private Python code.)
NTPsec 0.9.0 ("Initial NTPsec beta release") was 2015-11-16. According
to the git history of pylib/__init__.py, the "installable Python
libraries" came about on 2016-08-11.
The Python 2 EOL was originally, in 2008, announced to be 2015. However,
in 2014, it was extended to 2020:
https://www.python.org/doc/sunset-python-2/
So, for this to be an issue for _third-party_ code, all of the following
have to be true:
0. There is third-party code using NTPsec's Python library at all.
1. In late 2016 or later, knowing that Python 2's EOL was 2020 (albeit
also knowing it was extended once), someone wrote third-party Python 2
code that used NTPsec's Python library.
2. Now, in 2025, they still have not upgraded to Python 3, despite
Python 2 being EOL for 5 years.
3. They want to run the latest NTPsec code.
4. They can't or really don't want to upgrade to Python 3 now even if
forced by NTPsec dropping Python 2 support.
For #0, I'm not even sure what the actual uses cases would be. A
monitoring script that talks directly to the daemon rather than shelling
out to ntpq, maybe?
#1 seems like a toss-up at best (vs Python 3) as why would someone write
a brand new thing in Python 2 in 2016? But it's not impossible: maybe
they didn't have Python 3 on their system, due to it being an older
distro version.
But in the intervening years, they would have Python 3, so why not
upgrade the code? The NTPsec Python library is pretty small. I can't
imagine how the NTPsec Python library would be used in some massive
codebase where the 2 -> 3 upgrade is difficult. It's probably something
trivial, e.g. a Nagios monitoring script.
If they aren't upgrading their Python, why are they so concerned about
running the latest NTPsec code? In other words, if I just have an
ancient system that's sitting there running and I don't want to touch
it, this isn't an issue because I'm probably also not upgrading NTPsec.
As an aside... I'm certainly familiar with the complexities of upgrading
a large, legacy codebase. At $DAYJOB, we had a Django monolith using an
outdated and custom-patched Django, with a codebase that fought against
one or two specific Django conventions, that used Python 2. We couldn't
just upgrade to Python 3, as the old Django wouldn't work there. We
couldn't just upgrade Django, because we had all this custom stuff. We
had to carefully untangle all of that, which took a while. But that was
our fault, for making unsustainable choices. (Note that our choices had
already prevented us from upgrading Django itself, even staying on
Python 2.) We adjusted our approach with the upgrade and future upgrades
of our dependencies, mainly Django, have ranged from trivial to a few
days' work.
To be clear, I am talking about NTPsec only here. Other projects might
make a different calculus. For example:
On 2025-02-01 15:26, Gary E. Miller via devel wrote:
> I'm happy with Python 3, but every time gpsd breaks Python 2.7, I get
> complaints. Maybe this year is the last year to deal with this mess.
It wouldn't surprise me at all to find that people have written Python 2
code to talk to gpsd. And clearly, Gary is saying that's the case.
First, gpsd is surely more popular than NTPsec. Second, it has been
around longer, so there could more easily be existing code. Third, it
seems far more likely that there are use cases for third-party code to
interact with gpsd than with NTPsec.
It's not a
sustainable answer to expect to say on Python 3.4 forever.
Maybe not for everyone, but that should be the user's choice.
That doesn't obligate us to continue to support it.
One of the major things that NTPsec did when forking from NTP Classic
was drop all the old cruft. It's baffling to me that we are still having
this conversation here of all places.
--python=PYTHON python binary to be used [Default:
/usr/bin/python]
That option is a straight substitution, IIRC.
It's not just a straight substitution, for the reason I previously posted.
I'm sorry, that was my mistake. I was thinking of --pyshebang.
Removing polyXXX wrappers properly requires actually thinking about the
underlying code, a can that was kicked down the road by using the
wrappers in the first place.
Agreed.
--
Richard
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
