[RFC 0/2] python: integrate linter tests natively with meson

Daniel P. Berrangé posted 2 patches 1 month ago
meson.build                   |  1 +
python/meson.build            | 43 +++++++++++++++++++++++++++++++++++
python/qemu/qmp/qmp_tui.py    | 12 +++++-----
python/qemu/utils/qom_fuse.py |  2 +-
python/scripts/__init__.py    |  0
python/setup.cfg              |  8 -------
scripts/meson.build           |  9 ++++++++
tests/meson.build             |  1 +
tests/python/meson.build      | 17 ++++++++++++++
9 files changed, 78 insertions(+), 15 deletions(-)
create mode 100644 python/meson.build
create mode 100644 python/scripts/__init__.py
create mode 100644 tests/python/meson.build
[RFC 0/2] python: integrate linter tests natively with meson
Posted by Daniel P. Berrangé 1 month ago
It seems everytime I post some new patches which touch python code I
end up forgetting to run the extra non-default 'make check' target from
the python/ subdir.

IMHO, if we're going to pick up on linter failures in review feedback
(which is a reasonable thing to want to do), then we should be running
these linters by default in 'make check'.

This RFC is demonstrating a possible strategy to achieve that, by making
the python tests use meson in the same way as everything else, instead
of being stuck in the old 'make' world. In keeping with our work to
remove use of avocado for functional testing, this also removes avocado
for python linters since IMHO it adds no notable value over what meson
provides already.

See last patch for the interesting stuff, and the various caveats about
this initial PoC.

Being a PoC this is minimally tested beyond 'make check' on my local
machine.

Daniel P. Berrangé (2):
  python: be more selective in hiding mypy subclassing warning
  python: integrate linter tests natively with meson

 meson.build                   |  1 +
 python/meson.build            | 43 +++++++++++++++++++++++++++++++++++
 python/qemu/qmp/qmp_tui.py    | 12 +++++-----
 python/qemu/utils/qom_fuse.py |  2 +-
 python/scripts/__init__.py    |  0
 python/setup.cfg              |  8 -------
 scripts/meson.build           |  9 ++++++++
 tests/meson.build             |  1 +
 tests/python/meson.build      | 17 ++++++++++++++
 9 files changed, 78 insertions(+), 15 deletions(-)
 create mode 100644 python/meson.build
 create mode 100644 python/scripts/__init__.py
 create mode 100644 tests/python/meson.build

-- 
2.47.1


Re: [RFC 0/2] python: integrate linter tests natively with meson
Posted by Markus Armbruster 1 month ago
John, how does this mix with the linting parts of your "[PATCH 00/10]
qapi: misc testing and doc patches"?
Re: [RFC 0/2] python: integrate linter tests natively with meson
Posted by Daniel P. Berrangé 1 month ago
On Tue, Feb 25, 2025 at 07:04:11AM +0100, Markus Armbruster wrote:
> John, how does this mix with the linting parts of your "[PATCH 00/10]
> qapi: misc testing and doc patches"?

Since this is only an RFC, I would expect that John's patch series can
simply ignore this & merge when ready. If we decide to turn this into
a non-RFC series, than we can figure out the resolution at that point.
At a quick glance, I don't see anything John's done in his series that
would complicate life for this proposal in any notable way.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
Re: [RFC 0/2] python: integrate linter tests natively with meson
Posted by Markus Armbruster 1 month ago
Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, Feb 25, 2025 at 07:04:11AM +0100, Markus Armbruster wrote:
>> John, how does this mix with the linting parts of your "[PATCH 00/10]
>> qapi: misc testing and doc patches"?
>
> Since this is only an RFC, I would expect that John's patch series can
> simply ignore this & merge when ready. If we decide to turn this into
> a non-RFC series, than we can figure out the resolution at that point.
> At a quick glance, I don't see anything John's done in his series that
> would complicate life for this proposal in any notable way.

Okay.

Different question for John: do you think this RFC moves us in a forward
direction?