John Snow <jsnow@redhat.com> writes:
CI: https://gitlab.com/jsnow/qemu/-/pipelines/783612696
[Updated for v3, still all green.]
GL: https://gitlab.com/jsnow/qemu/-/commits/python-require-37
Hi, discussion about this series is ongoing. This series (v3) is not
meant to address all of that discussion, but rather is an updated
baseline for what we are capable of right now, today, without much
additional engineering. It's meant to serve as a reference for further
discussion.
Misses the RFC tag then :)
To my knowledge, the inconveniences caused by this patchset as currently
written are:
(1) Users of CentOS 8 and OpenSUSE 15.4 would need to install an
additional python package that will exist side-by-side with their
base platform's Python 3.6 package.
"zypper install python39" or "dnf install python38" is enough;
configure will do the rest of the work.
It's my understanding that this is largely a non-issue.
(2) Due to our Sphinx plugin that imports QAPI code from the tree,
I can read this as "Due to our Sphinx plugin (which by the way imports
some QAPI code)" or as "Due to out Sphinx plugin importing QAPI code".
The former is more accurate. We need a newer Sphinx because we use a
plugin, the plugin is written in Python, so our new Python requirement
applies. Fine print: the code the plugin imports from QAPI is going to
break first.
distro-provided versions of Sphinx that are installed and tied to
Python 3.6 will no longer be suitable. Users may forego building
docs or install a suitable sphinx using "pip".
It's my understanding that this one is "kind of a bummer".
I feel that the inconvenience caused by (1) is minimized as is possible;
the inconvenience caused by (2) is slightly worse and I concede the
workaround has some complexities that I would otherwise seek to avoid.
As far as I am aware, the way forward is to work with Paolo to implement
a proper venv solution for the build tree that will help mitigate the
fallout from (2) by automating the use of a pip-provided Sphinx in the
cases where the distro-provided version is insufficient.
So, your current plan is to rebase this series less its DO-NOT-MERGE
parts, on top of Paolo's. Correct?