Re: [PATCH 0/7] python: create installable package

[John Snow <jsnow@redhat.com>]

On 6/18/20 5:23 AM, Kevin Wolf wrote:
> Am 17.06.2020 um 22:27 hat John Snow geschrieben:
>>> In the Avocado project, we have a `make develop` rule that does that
>>> for the main setup.py file, and for all plugins we carry on the same
>>> tree, which is similar in some regards to the "not at the project root
>>> directory" situation here with "qemu/python/setup.py".
>>>
>>
>> Ah, yeah. If we're going this far, I'd prefer using a VENV over
>> modifying the user's environment. That way you can blast it all away
>> with a `make distclean`.
>>
>> Maybe the "make develop" target could even use the presence of a .venv
>> directory to know when it needs to make the environment or not ...
> [..]
>> For QEMU developers, installing with develop is going to be the smart
>> way to go. When your git tree is updated, your package will be updated
>> along with it. You can do it once and then probably forget about it.
> 
> I don't think we can make this a manual step at all. Building QEMU
> requires running some Python scripts (e.g. the QAPI generator), so the
> setup needs to be done either in configure or in a Makefile target that
> is specified as a dependency of any rule that would run a Python script.
> Building QEMU once would then be enough.
> 

I am imagining that we might treat "building" and "testing" separately
-- as it is, builds require python3.5 and tests requires 3.6 which
definitely necessitates two distinct environments.

I will admit that I haven't constructed a full, coherent vision of
python management that encapsulates both building ad testing yet. For
example, should configure/make expect to be run inside of a venv, or
should they expect to create and then enter the venv? That's not clear
to me yet. I'm simultaneously trying to work out with Peter Maydell how
the sphinx dependency should work. Sphinx is presently our only python
dependency for our build environment.)

Perhaps starting with the testing step is a good starting point and we
can use an implicit dependency on a `make develop` style step so it
happens automatically.

(But perhaps keeping it as a standalone target that CAN be invoked
manually would be nice if you want to do some more intensive debugging
or development of new tests.)

> Doing it automatically also means that we have to keep things local to
> the QEMU directory rather than installing them globally into the user
> directory. This is desirable anyway: Most of us deal with more than one
> QEMU source tree, so conflicts would be inevitable.
> 

I think it should be easy enough to put the VENV in the build directory
to prevent cross-contamination.

> Kevin
>