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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.