On Wed, 29 Jan 2025, Hal Murray wrote:
It's not about "with" in the sense of what's on the system; it's about
what Python version *their code* works with. Due to the large
incompatibilities between Python 2 and Python 3, it takes serious work to
update existing Python 2 code to work with Python 3. And such fixes
often impact code paths which are rarely used and poorly tested, leading
to long-lurking bugs associated with such updates. For example, SCons
was still fixing bugs related to Python 3 long after it dropped support
for Python 2 (making the "just run it with Python 2" workaround
impossible).
That makes sense. But I'm missing the next step. Do sites still using
mostly Python 2 have Python 3 available? Are they writing new code in
Python 2 or 3?
It's not about new code; it's about existing code that may not work with
Python 3.
Also note that Python 3 isn't the only Python version that breaks stuff;
it's just the most significant. E.g., if you want a sane interaction
between signals and select()/poll(), then you shouldn't use a version
later than 3.4, since they intentionally broke it in 3.5.
Can we build *with* 3 for *2* on those sites? Or would we even need to?
If they have 3 available, is it good enough if our code says it wants to
run on "python3" rather than "python"?
Does our code work in the build *with* 3 for *2* mode? I expect if it
finds 3 so it is building on 3 that it will build for 3 without a
configure option that doesn't yet exist.
We have:
--python=PYTHON python binary to be used [Default:
/usr/bin/python]
But that doesn't say if it's *with* or *for* so I assume the split doesn't
yet exist.
That option is for "for". The "with" is defined by whatever Python
version is used to run waf. The option is intended to allow them to be
different, but IIRC it doesn't currently work correctly, at least in some
cases.
Is there some specific reason to want to move to a newer waf, or is it
just a case of wanting the latest shiny new thing? Given the
excruciatingly poor state of waf documentation, the "if it ain't broke
don't fix it" philosophy is generally a safer choice.
Not quite the shiny thing, but close. There is:
ntpsec doesn't build with waf >= 2.1.0
https://gitlab.com/NTPsec/ntpsec/-/issues/830
but that's based on:
If not using the waf script bundled with ntpsec (as might be
required by distro-specific packaging guidelines),
Ah, I wasn't aware that it ever used an unbundled waf.
It would be nice to get the python 2 tangle out of the way. In one sense,
it's not a big deal. On the other hand, it's several minor pains in the
ass.
How many people/distros are running python 2 without python 3 being
available and also want to run ntpsec?
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.
On Thu, 30 Jan 2025, Hal Murray via devel wrote:
Richard Laager said:
Are there platforms (still worth supporting) that have Python 2 but not
Python 3 out of the box?
I think that's the key question.
Actually, no. That only applies to the "with", not the "for".
Anyone needing Python 2 can install it from a package, so it's not just
about what's bundled with the distro. Note that ntpsec itself is often
not bundled with a given distro, which doesn't mean that it can't be used
if someone wants it.
Fred Wright
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
