Re: [RFC PATCH v3 00/20] configure: create a python venv and ensure meson, sphinx

[John Snow <jsnow@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On Wed, Apr 26, 2023, 4:49 AM Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 4/26/23 10:05, Paolo Bonzini wrote:
> >>
> >
> > Thanks, this looks pretty good.  Some changes I'd make for the non-RFC
> > version:
> >
> > - I think we should just check in the meson wheel (which also removes
> > the need for patch 12, so it can be done in its stead) and remove the
> > submodule
>

OK, if there's no objections.

As a consequence, meson will likely never be downloaded from PyPI with the
patch set written as-is.

No real problem with that, just a difference.

>
> > - The verbosity of mkvenv.py can be tuned down and most prints replaced
> > with logger.info() or logger.debug()
>

😅

>
> > - While I agree with keeping patch 18 separate, I would move it earlier
> > so that patch 19 can be squashed into patch 14
> >


Agree. It was newer / more experimental so I kept it unsquash'd. If you
like it enough, asquashing I shall go.


> > - I am ambivalent about keeping --enable/--disable-pypi in the first
> > committed patchset, but in any case I would move patches 16 and 20
> > before patch 15
>

I might be stubborn but I think I want to keep it in for now. If it needs
redesigned to fit with the other flags you want to add, I think that's OK.

if we vendor the whl directly in qemu.git we won't need PyPI for meson, but
it's still useful for Sphinx so I think I'm still leaning towards keeping
it.

I'll try to refactor to keep it at the tail end of the series.


> Just one extra thing, since we're changing so much of Python handling
> and since the code is written, I would keep the Debian 10 workarounds
> for now, and only drop them after we drop support for 3.6.
>

This series was written assuming we get to drop 3.6 as a prereq. Is that
not the case?

Or did you mean to write 3.7 there?


> Paolo
>
>

[-- Attachment #2: Type: text/html, Size: 3780 bytes --]