Re: [PATCH v3 0/6] Python: Drop support for Python 3.6

[Paolo Bonzini <pbonzini@redhat.com>]

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