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. A 4 year cutoff in practice means that we would be able to drop Python 3.6 support for QEMU 7.1 (RHEL8 becomes 4 year old next May, while SLE is already over the threshold). In practice this means waiting until next April for John/Markus/myself, which I think is fair. Note that at least for now Meson need not to follow this rule; it is distributed with QEMU because configure must execute it before Make sets up the Python venv. This may change in the future of course, depending on the direction that the configure script takes with respect to setting up the venv, but I wouldn't hold my breath. However, the minimum required version of Meson of course must respect the oldest supported version of Python. Paolo [3] https://www.suse.com/c/the-first-prototype-of-adaptable-linux-platform-is-live/
