On Thu, Oct 30, 2025 at 4:40 AM Thomas Huth <[email protected]> wrote:
>
> On 28/10/2025 23.03, John Snow wrote:
> > This group is intended for packages required to run "make check"
> > successfully. Once qemu.qmp is fully divorced from the source tree, this
> > will primarily mean the qemu.qmp package. It specifically excludes
> > packages only needed to run the functional tests, which are not invoked
> > by default for "make check".
> >
> > Signed-off-by: John Snow <[email protected]>
> > ---
> > pythondeps.toml | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/pythondeps.toml b/pythondeps.toml
> > index 3d6907af799..70e83320855 100644
> > --- a/pythondeps.toml
> > +++ b/pythondeps.toml
> > @@ -31,6 +31,9 @@ meson = { accepted = ">=1.9.0", installed = "1.9.0",
> > canary = "meson" }
> > sphinx = { accepted = ">=3.4.3", installed = "6.2.1", canary =
> > "sphinx-build" }
> > sphinx_rtd_theme = { accepted = ">=0.5", installed = "1.2.2" }
> >
> > +[tests]
> > +qemu_qmp = { accepted = ">=0.0.5", installed = "0.0.5" }
> > +
> > [functests]
> > qemu_qmp = { accepted = ">=0.0.5", installed = "0.0.5" }
> > pygdbmi = { accepted = ">=0.11.0.0", installed = "0.11.0.0" }
>
> Hmm, "tests" is a string that is very hard to grep for, since it's used all
> over the place. Could we maybe continue to call this section "testdeps" or
> something else that is more unique?
Sure, you got it. I think I did name it that at one point and then
said "Well, these are all deps, that's kind of redundant", but
greppability is a reasonable thing.
checktests?
>
> Also, could the qemu_qmp be removed from the [functests] section now? As
> long as the python/qemu/qmp folder has not been removed yet, it should not
> be necessary - and as soon as it has been removed, the generic venv from
> "[tests]" should be in place, shouldn't it?
Sure, that's one way.
Pattern #1: each dependency group should contain everything it needs
to run the tests/functionality associated with that dependency group
Pattern #2: each dependency group should specify only the unique
packages associated with that functionality
#1: dep groups are self-contained and easy to invoke, but dep groups
could theoretically drift with conflicting package versions.
#2: package deps are factored out and can't conflict, but those
modifying the build system may need to remember that they need
multiple dependency groups for certain classes of test.
I went with #1; if we go to #2, it just means that functests need to
have a dependency on both tests/functests groups. That's fine too.
Which is better? I don't really actually have enough insight to have a
preference on this one. RFC?
On the subject of "make check-venv": I wasn't able to figure out how
to really specify the deps for functests yet, I am still kind of
hammering away at it like a child with a squeaky toy hammer... "make
check" will invoke (some) iotests; the deps I added to meson in this
series will adequately detect and cover this when you run this
high-level target. However, "make check" will also run some of the
func+quick tests, and I *didn't* specify the dependency there, and if
you run make check with -j#, those tests can actually fail. (Well,
once the in-tree library is removed, that is.)
Ideally I want to get rid of "make check-venv" entirely and use only
meson targets that add dependency groups on demand, so I need to
figure out the right places to inject these dependencies in the build
system, and I've been having trouble figuring that out.
>
> So maybe you could merge this patch with the previous one, simplifying the
> change here to something like this:
>
> diff --git a/pythondeps.toml b/pythondeps.toml
> --- a/pythondeps.toml
> +++ b/pythondeps.toml
> @@ -33,4 +33,6 @@ sphinx_rtd_theme = { accepted = ">=0.5", installed =
> "1.2.2" }
>
> [testdeps]
> qemu_qmp = { accepted = ">=0.0.5", installed = "0.0.5" }
> +
> +[functests]
> pygdbmi = { accepted = ">=0.11.0.0", installed = "0.11.0.0" }
>
> ?
If after my waffling above you still think that's the right way to go,
I'm happy to do it. I just need to figure out how to axe the
check-venv target, too, I think.
>
> Thomas
>
