Il mer 9 lug 2025, 20:39 John Snow <js...@redhat.com> ha scritto:

> You are right. However, the mkvenv configuration tool we pioneered has
> been largely un-noticed by contributors and appears to "just work" for
> the last several years. I believe that cost has been *largely*
> amortized by yours truly, and I have spared almost every other
> contributor from paying it.
>

Especially for sphinx.

mkvenv/pythondeps.toml has been very stable, perhaps beyond expectations,
so at least it was a one time cost.

So, more or less: your concern is something I share, but I think I
> have it satisfactorily addressed - hence my seeming overfocus on
> distro packagers.
>

I agree, and I should thank you for hearing me out on the somewhat crazy
idea that's mkvenv.

> In terms of 3rd party vendors, they can have similar roles to a distro
> > vendor, but are more likely to package up newer QEMU versions to run
> > on pre-existing distros.
>
> Yes. I think they are also usually more willing and able to bend the
> rules of the base platform, though.


Willing, I am not sure. Able yes, which is what matters even if they're not
really willing. :)

And they probably care much less about docs to be honest.

I seek to develop and codify a suitable compromise for these
> situations as they continue to arise and, in all likelihood, will not
> stop cropping up once per year or so. [...]  In my case, it's only Python
> packages from over five years

ago that present a difficulty - which is not exactly bleeding edge
> stuff.
>
> I would like to codify something like this for our support policy:
>
> "On otherwise supported build platforms, QEMU *may* require a Python
> interpreter that is considered actively maintained, which is usually a
> version released within the last five years. When platforms that ship,
> by default, an EOL Python interpreter also offer an optional package
> for a newer, actively maintained Python interpreter, QEMU may require
> this repository package for configuring and building QEMU."
>

That's basically an extension and clarification of what already exists at
https://www.qemu.org/docs/master/about/build-platforms.html ("Python
runtime").

Piggybacking on Python EOL as a necessary but not sufficient condition is
at the same time conservative and useful.

(Simpler language: I am trying to say that Platforms like OpenSUSE
> that have an ancient Python by default but also ship newer optional
> versions may require one of those newer, optional versions to build
> QEMU


OpenSUSE is not a problem since their base Python is not even supported by
QEMU. CentOS Stream is the more sticky one, unless you have a good reason
to require 3.10 (personally I don't, other than nicer type annotations I
have no love for e.g. match expressions).

On platforms that do NOT offer a newer Python version, I am
> suggesting that I will be shit-out-of-luck. I think this is a pretty
> mild compromise, all told.)
>

Yeah, their problem. Both Red Hat and SUSE have figured it out.

"On these platforms, unit tests and documentation may possibly require
> non-distribution packaged versions of Python dependencies such as
> Sphinx in order to run using the more modern Python interpreter."
>

That's the cop out for Red Hat, where you accept 3.9 for building and
require 3.10 for docs and tests? Not sure about it, especially tests. I
would either restrict the limitation to docs, or just declare 3.10 the
minimum once 3.9 is EOL (say January 2026).

I'd like to re-iterate that my motivation here is not to stop
> supporting EOL python versions "just because they are EOL", but rather
> instead because the tooling and libraries surrounding Python
> aggressively drop support for those versions once they become EOL.
> That is, 3.9 is not difficult to support until e.g. Python 3.14 comes
> out and setuptools, pip, and sphinx begin targeting 3.14 at the
> expense of 3.9 and there is an increased burden of hacks and
> workarounds required to target 3.9-3.14 inclusive.
>

Yes, this is the real problem. And it's better to have a plan ahead of time.

(As an aside, Meson is the good guy here. It supports old versions of
Python just fine The only reason to push Meson versions past 1.2 was to
support Rust-adjacent features and bugfixes that especially after 1.5 we're
mostly written by yours truly, specifically to evolve Rust support in the
direction that QEMU is interested in).

Paolo

Reply via email to