All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, John Snow <jsnow@redhat.com>
Cc: "Fam Zheng" <fam@euphon.net>,
	"Vladimir Sementsov-Ogievskiy" <vsementsov@virtuozzo.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	qemu-block@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	qemu-devel@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>, "Max Reitz" <mreitz@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH 0/7] python: create installable package
Date: Fri, 19 Jun 2020 17:09:16 +0200	[thread overview]
Message-ID: <95eb7bb7-577e-045f-3285-ae41194ff0bc@redhat.com> (raw)
In-Reply-To: <20200618092319.GA6012@linux.fritz.box>

On 6/18/20 11: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.
> 
> 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.

Indeed. Each of the source tree I use has its own virtual environment.
I personally stopped using the distribution packages, they don't make
sense when you develop, the tree changes too quickly.

Distributions use stable releases, so IMO it only makes sense to
generate a package along with releases. Else use venv.



  parent reply	other threads:[~2020-06-19 15:10 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03  0:15 [PATCH 0/7] python: create installable package John Snow
2020-06-03  0:15 ` [PATCH 1/7] python/qemu: create qemu.lib module John Snow
2020-06-05 12:33   ` Vladimir Sementsov-Ogievskiy
2020-06-03  0:15 ` [PATCH 2/7] python/qemu: formalize as package John Snow
2020-06-05 14:40   ` Vladimir Sementsov-Ogievskiy
2020-06-05 15:42     ` John Snow
2020-06-05 19:23     ` John Snow
2020-06-03  0:15 ` [PATCH 3/7] python/qemu: add README.rst John Snow
2020-06-05 14:56   ` Vladimir Sementsov-Ogievskiy
2020-06-05 16:18     ` John Snow
2020-06-03  0:15 ` [PATCH 4/7] python/qemu: Add pipenv support John Snow
2020-06-05 15:37   ` Vladimir Sementsov-Ogievskiy
2020-06-05 15:54     ` John Snow
2020-06-05 16:21   ` Vladimir Sementsov-Ogievskiy
2020-06-05 17:11     ` John Snow
2020-06-06  5:31       ` Vladimir Sementsov-Ogievskiy
2020-06-03  0:15 ` [PATCH 5/7] python/qemu: add pylint to pipenv John Snow
2020-06-03  0:15 ` [PATCH 6/7] python/qemu: Add flake8 " John Snow
2020-06-03  0:15 ` [PATCH 7/7] python/qemu: add mypy " John Snow
2020-06-06  5:53 ` [PATCH 0/7] python: create installable package Vladimir Sementsov-Ogievskiy
2020-06-08 14:14   ` John Snow
2020-06-17 19:52 ` Cleber Rosa
2020-06-17 20:27   ` John Snow
2020-06-18  9:23     ` Kevin Wolf
2020-06-19 15:04       ` John Snow
2020-06-19 16:44         ` Kevin Wolf
2020-06-19 17:14           ` John Snow
2020-06-19 15:09       ` Philippe Mathieu-Daudé [this message]
2020-06-19 15:15     ` Philippe Mathieu-Daudé
2020-06-19 16:10       ` John Snow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=95eb7bb7-577e-045f-3285-ae41194ff0bc@redhat.com \
    --to=philmd@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=fam@euphon.net \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.