Re: [PATCH v2 6/7] CI: Stop building docs on centos8

[Paolo Bonzini <pbonzini@redhat.com>]

On Tue, Feb 14, 2023 at 12:49 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> [quote]
> The motivation for this series is that Python 3.6 was EOL at the end of
> 2021; upstream tools are beginning to drop support for it, including
> setuptools, pylint, mypy, etc. As time goes by, it becomes more
> difficult to support and test against the full range of Python versions
> that QEMU supports. The closer we get to Python 3.12, the harder it will
> be to cover that full spread of versions.
> [/quote]
>
> this is all about new/eol versions of software upstream, and I don't
> think that's a justification. QEMU explicitly aims to use distro provided
> versions and upstream EOL status is not relevant in that context. Even
> if using "pip" to install it is possible to limit yourself to upstream
> releases which still support 3.6.
>
> There is the separate issue of Meson dropping python 3.6 which motivates
> Paolo's series. Again though, we don't have to increase our minimum meson
> version, because meson is working today. It is our choice to to increase
> it to use latest available meson features. At some point we can decide
> what we have is good enough and we don't have to keep chasing the latest
> features. Maybe we're not there yet, but we should think about when that
> would be.

In the case of Meson, the main advantage is moving _all_ of the
emulator configury out of the configure script.  This requires
add_global_dependencies which was added in 0.63.  So in that case it
is indeed mostly about shiny new features and it's not absolutely
necessary.

In the case of Python the issue is not the interpreter per se, though
there are a couple new feature in Python 3.7 that are quite nice (for
example improved data classes[1] or context variables[2]). The main
problem as far as I understood (and have seen in my experience) is
linting tools. New versions fix bugs that caused false positives, but
also become more strict at the same time. The newer versions at the
same time are very quick at dropping support for old versions of
Python; while older versions sometimes throw deprecation warnings on
new versions of Python. This makes it very hard to support a single
version of, say, mypy that works on all versions from RHEL8 and SLE15
to Fedora 38 and Ubuntu 23.04.

[1] https://peps.python.org/pep-0557/
[2] https://peps.python.org/pep-0567/

In fact this issue is the reason why RHEL9 does not package any of
these tools and does not run them as part of building RPMs even though
in principle it would be a good idea; it's too much of a pain to have
a single version that works across all the packages in the
distribution.

Regarding your other suggestion:

> * For non-native library/applications dependancies we aim
>   to support only the most recent distro version. Users
>   of older distros may need to dynamically fetch newer
>   deps.

I think this is a good idea, but one issue with "only supporting the
most recent distro version" is SUSE. While the most recent version of
SLE is about 5 years old, there is no next version in sight---SUSE
instead is working on their "Adaptable Linux Platform", but it's still
in the prototype stage[3]. So alternatively we could put a 4 or 5 year
cutoff after which you need to fetch newer deps. Considering the
delays between freeze and release of distros like RHEL or SLE, in
practice we would probably keep Python versions supported for 6-7
years.

A 4 year cutoff in practice means that we would be able to drop Python
3.6 support for QEMU 7.1 (RHEL8 becomes 4 year old next May, while SLE
is already over the threshold). In practice this means waiting until
next April for John/Markus/myself, which I think is fair.

Note that at least for now Meson need not to follow this rule; it is
distributed with QEMU because configure must execute it before Make
sets up the Python venv. This may change in the future of course,
depending on the direction that the configure script takes with
respect to setting up the venv, but I wouldn't hold my breath.
However, the minimum required version of Meson of course must respect
the oldest supported version of Python.

Paolo

[3] https://www.suse.com/c/the-first-prototype-of-adaptable-linux-platform-is-live/