Re: Python ecosystem versions overview

[Markus Armbruster <armbru@redhat.com>]

John Snow <jsnow@redhat.com> writes:

> On Tue, Jul 8, 2025, 7:23 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>> On 7/8/25 22:36, John Snow wrote:
>> > centos_stream_9     3.9.23   21.3.1  53.0.0      3.4.3   BaseOS, CRB
>>
>> Ok, so the lowest version of Sphinx (3.4.3) is currently used for CentOS
>> Stream 9.  It's supported for roughly 2 more years, until 12.0.
>>
>
> Yep. I am thinking however that because 3.9 is soon to be EOL this autumn,
> it may become reasonable to start requiring newer Python interpreters for
> this platform as well. They *are* available.
>
> I won't do it without a reason, but I think this may be a reasonable policy
> moving forward- If your platform is otherwise supported by our policy but
> ships a version of Python from more than five years ago (aka is EOL
> upstream), you *may* be required to install a newer, optional version (if
> and only if one is reasonably available from official distro repositories.)
>
> In general, this should have little to no impact except that isolated,
> offline builds (a la rpmbuild) may fail to produce documentation unless
> special considerations are taken for the build environment (namely, sphinx
> needs to be loaded for the newer interpreter).
>
> I think this is a reasonable compromise. If distributions want to package
> bleeding edge QEMU with five-years-old dependencies, they can expect to
> face *some* hurdles, and figuring out how to get sphinx as a builddep to
> build an optional component is not entirely unreasonable.

I agree.

Moreover, I can't see why we should invest into making such packaging
easy without a shred of evidence for anyone actually doing it.

> TLDR - I pledge to support any platform covered by our promise for
> building, but testing and documentation *requires* a non-EOL interpreter.
> This should have little to no effect for developers or users building from
> source or git, but has minor drawbacks for downstream maintainers of
> enterprise distributions that may attempt to backport bleeding edge QEMU
> versions.
>
>
>> > opensuse_leap_15_6  3.6.15   20.0.2  44.1.1      2.3.1   updates/sle,
>>
>> We use the 3.11 runtime in the dockerfile, see
>> tests/lcitool/mappings.yml.  That is a bare minimum install, so
>> configure won't use the distro sphinx and instead use 5.3.0 from
>> pythondeps.toml.
>>
>
> Yep, this tool was made to show the platform defaults only for now. Maybe
> I'll add a "show first party backports" flag in the future, if anyone more
> than just my own personal self would find that useful. (Speak up if so.)
>
>
>> > main/oss
>> > pkgsrc_current      3.12.11  25.1.1  80.9.0      8.2.3   ---
>> > ubuntu_22_04        3.10.12  22.0.2  59.6.0      4.3.2
>> > jammy-updates/main, jammy/universe, jammy/main
>>
>> This is the second oldest version of Sphinx.
>>
>
> With us until 26.04, in about 0.75 years. This seems like a reasonable new
> minimum if we wanted to increase it, though that does artificially drop
> support for RHEL9/CentOS stream building documentation from source under
> rpmbuild.
>
> (FWIW I probably can continue to support sphinx 3.x for a little while, the
> code is gross but it does appear functional. The only thing we *need* to do
> is bump the preferred version, I think. This support generally comes at the
> expense of type checking support for the docs code, as it's so gross I
> couldn't get it to work from 3.x to 8.x inclusive.)

It's gross, it's functional, it's impressive in a "don't do this at
home, kids" way, and it comes with a big, red "John, help!"  button for
you to smash in case of trouble.  Because the few smart enough to be
able to maintain that code are almost certainly much too smart to be
willing to maintain that code.

[...]