On Fri, May 13, 2022, 6:21 AM Paolo Bonzini <[email protected]> wrote:
> On 5/13/22 02:06, John Snow wrote:
> > The only downside I am really frowning at is that I will have to
> > replicate some "update the venv if it's outdated" logic that is usually
> > handled by the Make system in the venv bootstrapper. Still, I think it's
> > probably the only way to hit all of the requirements here without trying
> > to concoct a fairly complex Makefile.
> >
> > any thoughts? If not, I'll just move on to trying to hack up that
> > version next instead.
>
> I would not even bother with keeping the venv up to date. Just initialize
>
I'm worried about this idea being very inconvenient for iterative
development of the python code.
it in configure, this is exactly what configure remains useful for in the
> Meson-based world:
>
> - add configure options --enable-python-qemu={enabled,system,internal,pip,
> auto}/--disable-python-qemu (auto means system>internal>pip>disabled;
> enabled means
> system>internal>pip>error) and matching CONFIG_PYTHON_QEMU=y to
> config-host.mak
>
I'm not sure this makes sense. python/qemu will continue to exist in-tree
and will only ever be "internal" in that sense. It won't be something you
can wholesale install from pip.
i.e. I plan to continue to break off pieces and upstream them, but I intend
to leave several modules as internal only.
So I'm not sure "internal" vs "pip" makes sense config-wise, it's intended
to be a mixture of both, really.
But, I suppose this is how you'd like to address different venv setup
behaviors to accommodate spec builds vs dev builds - with a configure flag
of some kind.
(I suppose you'd then like to see configure error out if it doesn't have
the necessary requisites given the venv-style chosen?)
- use CONFIG_PYTHON_QEMU to enable/disable iotests in
> tests/qemu-iotests/meson.build
>
So it's just skipped if you don't have the reqs to make the venv? (Not an
error?)
> - add a configure option --enable-avocado=
> {system,pip,auto,enabled}/--disable-avocado and matching
> CONFIG_AVOCADO=y to config-host.mak
>
> - use it to enable/disable acceptance tests in tests/Makefile.include
>
And this is how you propose eliminating the need for an always-present
avocado builddep.
> - build the venv in configure and use the options to pick the right pip
> install
> commands, like
>
> has_python_module() {
> $python -c "import $1" > /dev/null 2>&1
> }
>
> # do_pip VENV-PATH VAR PACKAGE [PATH] -- PIP-OPTIONS
> do_pip() {
> local num_args source
> num_args=5
> test $4 = '--' && num_args=4
> eval source=\$$2
> # Try to resolve the package using a system install
> case $source in
> enabled|auto|system)
> if has_python_module $3; then
> source=system
> elif test $source = system; then
> error_exit "Python package $3 not installed"
> fi
> esac
> # See if a bundled copy is present
> case $source in
> enabled|auto|internal)
> if test $num_args = 5 && test -f $4/setup.cfg; then
> source=internal
> elif test $source = internal; then
> error_exit "Sources for Python package $3 not found in the QEMU
> source tree"
> fi
> esac
> # Install the bundled copy or let pip download the package
> case $source in
> internal)
> # The Pip error message should be clear enough
> (cd $1 && . bin/activate && pip install "$@") || exit 1
> ;;
> enabled|auto|pip)
> shift $num_args
> if (cd $1 && . bin/activate && pip install "$@"); then
> source=pip
> elif test $source = auto; then
> source=disabled
> else
> # The Pip error message should be clear enough
> exit 1
> fi
> ;;
> esac
> eval $2=\$source
> }
>
> rm -rf venv/
> $python -m venv venv/
> do_pip venv/ enable_python_qemu qemu.qmp python/qemu -- qemu.qmp
> do_pip venv/ enable_avocado avocado -- -r tests/requirements.txt
>
Won't this rebuild the venv like *all of the time*, basically whenever you
see the "configuration is stale" message?
That both seems like way too often, *and* it wouldn't cover cases when it
really ought to be refreshed.
