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é <berra...@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 :|
