On 2/21/23 08:00, Markus Armbruster wrote:
> 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?
Yes, I will post a non-RFC v4 once all the feedback is gathered.
Paolo