On Tue, Sep 9, 2025 at 6:37 AM Thomas Huth <th...@redhat.com> wrote: > > On 07/08/2025 23.46, John Snow wrote: > > On Thu, Jul 24, 2025 at 3:47 PM Thomas Huth <th...@redhat.com> wrote: > >> > >> On 21/07/2025 22.38, John Snow wrote: > >>> On Thu, Jul 17, 2025 at 4:44 AM Alex Bennée <alex.ben...@linaro.org> > >>> wrote: > >> ... > >>>> Am I holding it wrong? > >>>> > >>>> ➜ ./pyvenv/bin/python ../../tests/functional/test_aarch64_virt.py > >>>> --help > >>>> Traceback (most recent call last): > >>>> File > >>>> "/home/alex/lsrc/qemu.git/builds/all/../../tests/functional/test_aarch64_virt.py", > >>>> line 16, in <module> > >>>> from qemu_test import QemuSystemTest, Asset, > >>>> exec_command_and_wait_for_pattern > >>>> File > >>>> "/home/alex/lsrc/qemu.git/tests/functional/qemu_test/__init__.py", line > >>>> 14, in <module> > >>>> from .testcase import QemuBaseTest, QemuUserTest, QemuSystemTest > >>>> File > >>>> "/home/alex/lsrc/qemu.git/tests/functional/qemu_test/testcase.py", line > >>>> 26, in <module> > >>>> from qemu.machine import QEMUMachine > >>>> ModuleNotFoundError: No module named 'qemu' > >>>> > >>>> I thought the point of the venv is we had all the modules we need > >>>> automatically available to the PYTHONPATH? > >>> > >>> As Thomas points out, "qemu" is special since it's already in the > >>> tree. There has been some dragging-of-feet by yours-truly because > >>> installing the "qemu" module by default when running configure > >>> introduces a considerable startup lag time, and the module is not > >>> actually needed for the simple configuration and building of QEMU - > >>> only testing. > >>> > >>> It's something I want to fix, but must admit to being a bit stumped as > >>> to how I will bridge that gap long term. Currently, all of the modules > >>> we need are in the tree with no dependencies, so it can be fixed with > >>> a simple PYTHONPATH hack. However, if I actually remove the QMP > >>> library from the tree like I have wanted to, then we need pip to do a > >>> real install and process dependencies, and this creates some > >>> complications and extra startup lag. > >> > >> Wouldn't it be possible to add the module as a wheel in python/wheels/ ? > >> That's maybe the easiest solution, isn't it? > > > > The qemu.qmp wheel, yes, because it's purepython. The part I am > > worried about is that by removing qemu.qmp from the tree, you cannot > > just use the PYTHONPATH hack anymore to use the remaining in-tree > > goodies, namely the machine module used extensively throughout > > testing, because they will now rely on an external dependency. > > Would it maybe be possible to add the machine part to the qemu.qmp module, > too? (Gerd also ask me at KVM forum about this, so there is certainly > interest for extending the qemu.qmp module with the machine part)
I could, can you explain a little why we want it? It would involve cleaning up the interfaces a good deal and while I don't think it is hard, it will be a lot of clerical work and shuffling for a little while. I have some drafts somewhere that add an asyncio VM appliance to replace the existing one in the same manner as for what I did for async QMP to help solve the complicated logging stack we have for VM console scripts. Having a solid justification and guinea pigs^H^H^H^H^H^H^H^H^H^H^H^H beta users would push the project over the line for me. > > > I'm sure it's solvable, I just tried once a while back and hit a wall, > > got distracted, and haven't revisited it yet... Maybe a good > > rubber-ducking session would help. > > For the (removed) avocado tests, they had a dependency on the "check-venv" > target in QEMU, so its python dependencies were only added when you ran > "make check-avocado". We could maybe do the same for "check-functional", too? Something like that, yeah. I'm going to send a patchset soon that does the dumbest possible thing and we can chat in review for that series.
