On Wed, Jul 9, 2025, 3:40 PM Paolo Bonzini <pbonz...@redhat.com> wrote:
> > > 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. > I knew it was possible, I was not so sure it'd be as stable as it has been. What a delight! > > 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). > Just an example for a distro we've already bent the rules for. Their base Python is still technically 3.6 and they don't technically package Sphinx for the newer interpreter, so it's a useful example case even if it is arguably beyond our support window now. > > 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. > I meant to suggest it's *my* problem, but I think distributions are aware that not providing an (optional) non-EOL Python is not a viable option these days. Basically affirming: you will be able to build QEMU on a supported platform with just your distro's repositories, and that's a promise. > "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 mean to say that I don't consider loading a newer Python provided by your distribution as a violation of our platform promise: in many ways it is "just another dep". I wouldn't raise the minimum Python version unless affected distributions had an alternate interpreter in their repository. OpenSUSE and CentOS both offer this, so the option is viable. However, this solution does not account for other Python dependencies like Sphinx, which are very likely *not* repackaged by the distro for the newer interpreter. A normal end user can run configure and get the new deps automatically and invisibly, no problem. Offline/isolated builds are slightly trickier. So I mean to clarify: QEMU will always be able to be built with your distro packages (sometimes with newer, alternative Python versions) but in this specific case, some "optional" features where Python is concerned may require side-loading Python dependencies from outside of your system repository. I.e. there may be degradation, but only for unit tests and docs, and only when your base platform Python is EOL (five years old. It can be fixed by using PyPI, allowing internet during configure, disabling tests and docs, or doing the labor of adding a new package to your builddep environment. So I pledge the core build will only need the newer Python from your system repo, but tests and docs I only pledge support for if your Python is not EOL (approx 5 years old or less.) That's my proposal. (Unless... haha. The idea is so stupid I don't even want to write it on list. Ping me on matrix/IRC...) > 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). > I love Meson. Pure Python, zero deps. Trivial to vendor. It's a delight and I'm glad they have such reasonable policies. It's a rare treat that never causes problems for me <3 > Paolo >
