qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits:


From: Ani Sinha
Subject: Re: venv for python qtest bits? (was: Re: [PATCH 11/12] acpi/tests/bits: add README file for bits qtests)
Date: Tue, 28 Jun 2022 13:19:34 +0530

On Tue, Jun 28, 2022 at 12:55 PM Thomas Huth <thuth@redhat.com> 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.

Not sure what you mean by directly using the venv.

>
>   Thomas
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]