Re: [PATCH RFC 0/6] Switch iotests to pyvenv

[John Snow]

On Thu, Jun 22, 2023 at 5:24 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On Wed, Jun 21, 2023 at 9:08 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
> > Maybe patch 4 can use distlib.scripts as well to create the check script in 
> > the build directory? (Yes that's another mkvenv functionality...) On a 
> > phone and don't have the docs at hand, so I am not sure. If not, your 
> > solution is good enough.
> >

Yeah, that's a possibility... we could "install" the iotests script.
That might keep things simple. I'll investigate it.

> > Apart from this the only issue is the speed. IIRC having a prebuilt .whl 
> > would fix it, I think for Meson we observed that the slow part was building 
> > the wheel. Possibilities:
> >
> > 1) using --no-pep517 if that also speeds it up?
> >
> > 2) already removing the sources to qemu.qmp since that's the plan anyway; 
> > and then, if you want editability you can install the package with --user 
> > --editable, i.e. outside the venv
>
> Nope, it's 3 second always and 1.5 even with the wheel.
>
> Maybe replace qemu.qmp with a wheel and leaving PYTHONPATH for the rest?
>
> Paolo
>

Hm, I guess so. It's just disappointing because I was really hoping to
be able to use "pip install" to handle dependencies like a normal
package instead of trying to shoulder that burden with an increasing
amount of custom logic that's hard for anyone but me (or you, now) to
maintain.

It kind of defeats the point of having formatted it as a package to begin with.

Maybe there's a sane way to amortize the cost of installation by not
re-creating it after every call to configure instead -- the rest of
the script is fast enough, perhaps we could default clear to *False*
from now on and use the _get_version() bits to detect if the local
internal package is already installed or not -- and if it is, just
leave it alone.

If we always install it in editable mode, and the path where it is
"installed" is what we expect it to be, it shouldn't have any problems
with being out of date.... I think. We could conceivably use the
"faux" package version the internal package has to signal when the
script needs to re-install it.

Something like that?

--js