On Tue, Dec 9, 2025 at 2:46 PM Daniel P. Berrangé <[email protected]> wrote: > > On Tue, Dec 09, 2025 at 12:23:21PM -0500, John Snow wrote: > > On Tue, Dec 9, 2025, 12:00 PM Daniel P. Berrangé <[email protected]> > > wrote: > > > > > On Fri, Dec 05, 2025 at 01:00:42AM -0500, John Snow wrote: > > > > Hello! > > > > > > > > This series drops the in-tree version of our python-qemu-qmp package > > > > ("qemu.qmp") in favor of the version hosted on PyPI, whose repository is > > > > located at https://gitlab.com/qemu-project/python-qemu-qmp. > > > > > > > > GitLab CI: https://gitlab.com/jsnow/qemu/-/pipelines/2197613036 > > > > (FreeBSD isn't my fault...!) > > > > > > > > The major effects of this patch series are: > > > > > > > > 1. qemu.qmp will be installed from PyPI or vendored packages instead of > > > > being utilized directly from the qemu.git tree. > > > > > > This is not getting installed in enough scenarios IMHO. > > > > > > > It's hard to trigger an install when you don't use the build system, > > Well I am using the build system in the same way that I've always > used it with QEMU. IOW, the benchmark for this is the current way > things work with the python stuff in tree. The ideal would be to > match that behaviour with no workflow changes needed, if it is > practical to achieve that without major downsides.
I know, but if we add out-of-tree things, there's some fundamental things that change - we need to load that dependency somewhere, somewhen. > > > though... If you bypass make/meson/ninja entirely I'm not really sure what > > I can do to bootstrap the test deps. > > Can we just do it unconditionally in configure / meson ? These aren't > big files to download, and we're already dealing other python stuff > for the build, and git submodules, and rust crates. Pulling in qemu.qmp > doesn't feel like it is a burden to do by default ? I definitely could, and I think it would be rather convenient; I only have some minor concerns about it: - We don't promise tests on all platforms that we promise builds on. We have definitely broken this in the past. It might work currently, but it's a line I want to be aware we are crossing. It may necessitate python3-wheel and python3-setuptools just to build in this case. That's probably not an issue on workstations, but it's more bricks on the wall that are actually not truly needed until you run tests (or prepare to run tests). - Configure will get slower by default. I can install the core test deps by default if people don't mind the additional delay time. It might be something like 2-4 seconds, depending. If you don't care, I don't. - Things like functional tests are still going to require some kind of environment prep for all the extra stuff they require, I don't think it's reasonable to preload all of that stuff at configure time, and we never have. "make check-functional" is sufficient to pull those deps in, but if there are ways to engage the functional tests manually that people are using, I think another preparation step is unavoidable there. So, in addition to the "pyrun" wrapper I mailed in a separate reply (which I think is a good idea anyway, regardless of what direction we go here), I see two main paths that address your issues in differing amounts: (1) make configure prepare the test deps *by default*, adding a flag like --without-test-deps to disable it, or (2) Continue not prepping the test deps, but allow --with-test-deps to pre-load them. More or less the same solution, just with different defaults. I'm fairly ambivalent, my only personal "habit" here is "I am really reluctant to touch configure unless there is a strong consensus around it because I dislike having to make arguments at that level." > > > 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 :| >
