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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Feb 16, 2023 at 02:46:18AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Tue, Feb 14, 2023 at 09:52:44PM +0100, Paolo Bonzini wrote:
> >> Il mar 14 feb 2023, 18:26 Kevin Wolf <kwolf@redhat.com> ha scritto:
> >> 
> >> > Am 14.02.2023 um 15:03 hat Paolo Bonzini geschrieben:
> >> > > 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.
> >> >
> >> > Why do we have to support a single version of mypy? What is wrong with
> >> > running an old mypy version with old Python version, and a newer mypy
> >> > with newer Python versions?
> >> >
> >> > Sure, they will complain about different things, but it doesn't feel
> >> > that different from supporting multiple C compilers in various versions.
> >> >
> >> 
> >> It's more like having to support only C++03 on RHEL 8 and only C++20 in
> >> Fedora 37, without even being able to use a preprocessor.
> >> 
> >> For example old versions might not understand some type annotations and
> >> will fail mypy altogether, therefore even with newer versions you can't
> >> annotate the whole source and have to fall back to non-strict mode.
> >
> > In terms of back compatibility, is there a distinction to be
> > made between mypy compat and the python runtime compat ?
> >
> > If we add annotations wanted by new mypy, and old mypy doesn't
> > understand them, that's not a huge problem. We can simply declare
> > that we don't support old mypy, and skip the validation tests if
> > old mypy is installed.
> 
> In theory, type hints are transparent at run time.  In practice, use of
> modern type hints is known to break 3.6 at run time.  I don't remember
> the details offhand, but John should be able to dig them up if you're
> interested.
> 
> So, it should not be a problem, but it is.

Ok, this is a pretty compelling motivating factor for dropping
3.6, as it is clear demonstration that we're being held back
by the unfortunate lack of runtime compatibility.

For most of the other problems we can simply mandate a new
enough version of the add on tool, but if using new mypy
requires annotations that break at runtime on 3.6 that's
a painful blocker.



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 :|