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

John Snow posted 6 patches 1 year, 2 months ago
Failed in applying to current master (apply log)
There is a newer version of this series
docs/conf.py                                  |  4 +-
docs/meson.build                              |  2 +-
configure                                     | 41 ++++++++++++++-----
python/Makefile                               | 10 ++---
python/setup.cfg                              |  7 ++--
python/tests/minreqs.txt                      |  2 +-
scripts/qapi/mypy.ini                         |  2 +-
tests/docker/dockerfiles/centos8.docker       |  5 +++
tests/docker/dockerfiles/opensuse-leap.docker |  1 +
9 files changed, 50 insertions(+), 24 deletions(-)
[PATCH v3 0/6] Python: Drop support for Python 3.6
Posted by John Snow 1 year, 2 months ago
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.

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,
    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.

OK, seeya later!
--js

John Snow (6):
  configure: Look for auxiliary Python installations
  configure: Add courtesy hint to Python version failure message
  DO-NOT-MERGE: testing: Add Python >= 3.7 to Centos, OpenSuSE
  DO-NOT-MERGE: testing: add pip-installed sphinx-build to CentOS 8
  meson: prefer 'sphinx-build' to 'sphinx-build-3'
  Python: Drop support for Python 3.6

 docs/conf.py                                  |  4 +-
 docs/meson.build                              |  2 +-
 configure                                     | 41 ++++++++++++++-----
 python/Makefile                               | 10 ++---
 python/setup.cfg                              |  7 ++--
 python/tests/minreqs.txt                      |  2 +-
 scripts/qapi/mypy.ini                         |  2 +-
 tests/docker/dockerfiles/centos8.docker       |  5 +++
 tests/docker/dockerfiles/opensuse-leap.docker |  1 +
 9 files changed, 50 insertions(+), 24 deletions(-)

-- 
2.39.0

Re: [PATCH v3 0/6] Python: Drop support for Python 3.6
Posted by Markus Armbruster 1 year, 2 months ago
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?

> OK, seeya later!
Re: [PATCH v3 0/6] Python: Drop support for Python 3.6
Posted by Paolo Bonzini 1 year, 2 months ago
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