On Thu, Oct 09, 2025 at 01:26:25PM +0200, Paolo Bonzini wrote: > On Thu, Oct 9, 2025 at 10:58 AM Daniel P. Berrangé <[email protected]> > wrote: > > > > On Thu, Oct 09, 2025 at 10:22:43AM +0200, Paolo Bonzini wrote: > > > On Thu, Oct 9, 2025 at 9:52 AM Daniel P. Berrangé <[email protected]> > > > wrote: > > > > I've proposed removing them in favour of meson rules earlier > > > > this year: > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2025-02/msg04920.html > > > > > > I mostly agree with the intent of integrating tests with the > > > configure/pyvenv/meson infrastructure, but I'd do things in a > > > different order: > > > > > > - split part of scripts/ into contrib/scripts/ to identify one-off > > > scripts vs. what is really used in the build process > > > > IMHO we should rather aim to eliminate contrib. We should either care > > about the contents, and find an appropriate home for it in tree & have > > ability to install it, or they should live outside QEMU git in their > > own home. > > > > We shouldn't encourage a "dumping ground" for stuff that we don't > > know what to do with. > > I don't disagree but we have a lot of scripts like that: > > scripts/analyse-9p-simpletrace.py > scripts/analyse-locks-simpletrace.py > scripts/compare-machine-types.py > scripts/dump-guest-memory.py > scripts/get-wraps-from-cargo-registry.py > scripts/python_qmp_updater.py > scripts/qcow2-to-stdout.py > scripts/qemu-gdb.py > scripts/qom-cast-macro-clean-cocci-gen.py > scripts/render_block_graph.py > scripts/replay-dump.py > scripts/simpletrace.py > scripts/u2f-setup-gen.py > scripts/userfaultfd-wrlat.py > > and a bunch more that aren't .py so I didn't check them; plus entire > directories: > > scripts/coccinelle/ > scripts/codeconverter > scripts/coverage/ > scripts/kvm/ > scripts/performance/ > scripts/simplebench/ > > Separating them would be useful. > > > > - move python/scripts/ to scripts/venv/, adjusting python/tests > > > > > > - move tests/minreqs.txt to pythondeps.toml. switch from pip to mkvenv > > > in tests/Makefile. > > > > > > - unifying the test scripts for all of scripts/, as much as possible > > > > > > - integrate tests in meson, but keeping the shell scripts for now. > > > move python/tests to tests/python. add a custom_target() to do "mkvenv > > > ensuregroup tests" > > > > > > - move tox usage to .gitlab-ci.d, placing tox outside the configure > > > script instead of inside. this makes the QEMU venv a "child" of the > > > tox venv rather than the opposite, and allows more testing than just > > > running the linters > > > > If tox is outside, that seems to require that we re-run configure for > > each different python version we want to run tests with, which feels > > pretty undesirable. > > > > There's the (system) python version that we want to run the overall > > build system with, and then there are N other python versions which > > we want to be able to run linters against. > > I think we do want to check that configure can set up a virtual > environment for all those versions of Python. Then we can use the > virtual environment to run the linters too. > > In fact I'm not even sure we need tox. Thanks to mkvenv, we would be > using "configure --python" as a much cheaper substitute of tox. The > only thing that is lost is the ability to test all versions through a > single build tree, but I'm not sure the complexity is worth it.
FWIW, from my POV as a contributor, what I dislike is submitting a patch series that has run through "make check" and then getting complaints from maintainers that it fails various tests that are not run as part of "make check". If the maintainer is going to send feedback about failures under 5 different versions of python, then IMHO 'make check' needs to be validating those 5 different versions of python in one go. That was what my patch series aimed to address. I'm not bothered whether we use tox or directly call mkvenv to setup our test envs, provided we don't end up running configure; make; make check for each python version we want linter checks against. 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 :|
