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. > 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 ? 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 :|
