From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"John Snow" <jsnow@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Cleber Rosa" <crosa@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>,
"Michael Roth" <michael.roth@amd.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
Qemu-block <qemu-block@nongnu.org>,
"Hanna Reitz" <hreitz@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Kevin Wolf" <kwolf@redhat.com>
Subject: Re: [PATCH v2 6/7] CI: Stop building docs on centos8
Date: Tue, 14 Feb 2023 14:17:52 +0000 [thread overview]
Message-ID: <Y+uYEKYQB+8kjtEx@redhat.com> (raw)
In-Reply-To: <CABgObfb-_upmc=36_bnxLMCB+0KqWoZNK62rnD5KpBKhW4N+hw@mail.gmail.com>
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 :|
next prev parent reply other threads:[~2023-02-14 14:18 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 0:31 [PATCH v2 0/7] Python: Drop support for Python 3.6 John Snow
2023-02-10 0:31 ` [PATCH v2 1/7] python: support pylint 2.16 John Snow
2023-02-10 0:31 ` [PATCH v2 2/7] python: drop pipenv John Snow
2023-02-10 0:31 ` [PATCH v2 3/7] configure: Look for auxiliary Python installations John Snow
2023-02-10 7:39 ` Thomas Huth
2023-02-10 10:45 ` Paolo Bonzini
2023-02-10 15:28 ` John Snow
2023-02-10 15:53 ` Peter Maydell
2023-02-10 16:17 ` Paolo Bonzini
2023-02-10 16:21 ` John Snow
2023-02-10 16:26 ` Paolo Bonzini
2023-02-10 19:56 ` Eric Blake
2023-02-10 0:31 ` [PATCH v2 4/7] configure: Add nice hint to Python failure message John Snow
2023-02-10 7:45 ` Thomas Huth
2023-02-10 19:19 ` John Snow
2023-02-10 0:31 ` [PATCH v2 5/7] DO-NOT-MERGE: testing: Add Python >= 3.7 to Centos, OpenSuSE John Snow
2023-02-10 0:31 ` [PATCH v2 6/7] CI: Stop building docs on centos8 John Snow
2023-02-10 7:06 ` Philippe Mathieu-Daudé
2023-02-10 10:41 ` Peter Maydell
2023-02-10 16:01 ` John Snow
2023-02-10 16:32 ` Peter Maydell
2023-02-10 16:51 ` Daniel P. Berrangé
2023-02-10 17:15 ` Peter Maydell
2023-02-10 18:27 ` Paolo Bonzini
2023-02-15 12:30 ` Daniel P. Berrangé
2023-02-14 7:40 ` Markus Armbruster
2023-02-14 8:35 ` Thomas Huth
2023-02-14 9:59 ` Alex Bennée
2023-02-14 12:10 ` Daniel P. Berrangé
2023-02-16 1:08 ` Markus Armbruster
2023-02-16 11:00 ` Daniel P. Berrangé
2023-02-14 10:33 ` Peter Maydell
2023-02-14 11:03 ` Kevin Wolf
2023-02-15 19:17 ` Markus Armbruster
2023-02-14 11:48 ` Daniel P. Berrangé
2023-02-14 14:03 ` Paolo Bonzini
2023-02-14 14:17 ` Daniel P. Berrangé [this message]
2023-02-14 17:26 ` Kevin Wolf
2023-02-14 20:52 ` Paolo Bonzini
2023-02-15 10:38 ` Kevin Wolf
2023-02-15 11:35 ` Daniel P. Berrangé
2023-02-16 1:46 ` Markus Armbruster
2023-02-16 11:06 ` Daniel P. Berrangé
2023-02-17 22:49 ` John Snow
2023-02-20 8:51 ` Markus Armbruster
2023-02-16 11:12 ` Daniel P. Berrangé
2023-02-16 10:40 ` Markus Armbruster
2023-02-10 17:55 ` John Snow
2023-02-10 18:09 ` Peter Maydell
2023-02-10 20:31 ` Paolo Bonzini
2023-02-10 0:31 ` [PATCH v2 7/7] Python: Drop support for Python 3.6 John Snow
2023-02-10 10:04 ` [PATCH v2 0/7] " Markus Armbruster
2023-02-14 18:35 ` John Snow
2023-02-15 10:53 ` Kevin Wolf
2023-02-15 19:05 ` Markus Armbruster
2023-02-16 10:17 ` Peter Maydell
2023-02-16 12:31 ` Markus Armbruster
2023-02-16 10:58 ` Thomas Huth
2023-02-17 9:06 ` Markus Armbruster
2023-02-17 9:56 ` Thomas Huth
2023-02-17 15:37 ` Peter Maydell
2023-02-17 15:41 ` Daniel P. Berrangé
2023-02-17 10:01 ` Daniel P. Berrangé
2023-02-17 20:46 ` John Snow
2023-02-20 6:16 ` Thomas Huth
2023-02-20 19:56 ` John Snow
2023-02-21 12:00 ` Thomas Huth
2023-02-17 11:37 ` Proposed way forward " Daniel P. Berrangé
2023-02-17 13:46 ` Thomas Huth
2023-02-17 13:52 ` Daniel P. Berrangé
2023-02-17 14:40 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y+uYEKYQB+8kjtEx@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=bleal@redhat.com \
--cc=crosa@redhat.com \
--cc=hreitz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).