On Tue, Jun 28, 2022 at 1:19 PM Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Tue, Jun 28, 2022 at 09:25:35AM +0200, Thomas Huth wrote: > > On 28/06/2022 09.10, Michael S. Tsirkin wrote: > > > On Tue, Jun 28, 2022 at 09:03:33AM +0200, Thomas Huth wrote: > > > > > > > > > > No problem with that. So that's venv. But do we need pip > > > > > > > > > > and pulling > > > > > > > > > > packages from the net during testing? > > > > > > > > > > > > > > > > > > We do that too. See requirements.txt in tests/ > > > > > > > > > Following two are downloaded: > > > > > > > > > avocado-framework==88.1 > > > > > > > > > pycdlib==1.11.0 > > > > > > > > > > > > > > > > > > Also see this line in Makefie.include: > > > > > > > > > > > > > > > > > > $(call quiet-venv-pip,install -r $(TESTS_VENV_REQ)) > > > > > > > > > > > > > > > > Right but that's avocado since it pulls lots of stuff from > > > > > > > > the net anyway. > > > > > > > > Are the libraries in question not packaged on major distros? > > > > > > > > > > > > > > Currently I only need this: > > > > > > > https://github.com/python-tap/tappy > > > > > > > which is the basic TAP processing library for python. > > > > > > > > > > > > > > It seems its only installed through pip: > > > > > > > https://tappy.readthedocs.io/en/latest/ > > > > > > > > > > > > > > I do not think this is packaged by default. It's such a basic > > > > > > > library > > > > > > > for parsing test output that maybe we can keep this somewhere > > > > > > > within > > > > > > > the python src tree? Not sure ... > > > > > > > > > > > > It's pretty small for sure. Another submodule? > > > > > > > > > > Unlike BITS, this one is likely going to be maintained for a while and > > > > > will receive new releases through > > > > > https://pypi.org/project/tap.py/ > > > > > so forking is OK but someone has to keep this updated. > > > > > > > > > > I am open to anything. Whatever feels right is fine to me. > > > > > > > > John Snow is currently working on the "Pythonification" of various QEMU > > > > bits, I think you should loop him into this discussion, too. > > > > > > > > Thomas > > > > > > submodule does not mean we fork necessarily. We could have > > > all options: check for the module and use it if there, if not > > > use one from system if not there install with pip .. > > > But yea, I'm not sure what's best either. > > > > submodules create a dependency on an internet connection, too. So before you > > add yet another submodule (which have a couple of other disadvantages), I > > think you could also directly use the venv here. > > Definitely not submodules. > > We need to get out of the mindset that submodules are needed for every new > dependancy we add. Submodules are only appropriate if the external project > is designed to be used as a copylib (eg the keycodemapdb tool), or if we > need to bundle in order to prevent a regression for previously deployed > QEMU installs where the dependancy is known not to exist on all our > supported platforms. > > This does not apply in this case, because the proposed use of tappy is > merely for a test case. Meson just needs to check if tappy exists and if > it does, then use it, otherwise skip the tests that need it. The user can > arrange to install tappy, as they do with the majority of other deps. > > If John's venv stuff is relevant, then we don't even need the meson checks, > just delegate to the venv setup. > > Regardless, no submodules are needed or desirable.
What about keeping biosbits stuff? Source or pre-built. > > 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 :| >
