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

[Daniel P . Berrangé]

On Tue, Feb 14, 2023 at 03:03:54PM +0100, Paolo Bonzini wrote:
> 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.

Yeah, that kind of problem with very old SUSE would push towards
simply excluding the LTS distros, or excluding them if they're
older than N years, and expect users of such old distros to
download newer python modules, etc.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|