On 6/19/20 12:44 PM, Kevin Wolf wrote:
> Am 19.06.2020 um 17:04 hat John Snow geschrieben:
>> 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, a
Am 19.06.2020 um 17:04 hat John Snow geschrieben:
> 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
> >>>
On 6/19/20 11:15 AM, Philippe Mathieu-Daudé wrote:
> On 6/17/20 10:27 PM, John Snow wrote:
>>
>>
>> On 6/17/20 3:52 PM, Cleber Rosa wrote:
>>> On Tue, Jun 02, 2020 at 08:15:16PM -0400, John Snow wrote:
> [...]
>>> Are you proposing that we have, say, "python-qemu" version 10, being
>>> the 10th
On 6/17/20 10:27 PM, John Snow wrote:
>
>
> On 6/17/20 3:52 PM, Cleber Rosa wrote:
>> On Tue, Jun 02, 2020 at 08:15:16PM -0400, John Snow wrote:
[...]
>> Are you proposing that we have, say, "python-qemu" version 10, being
>> the 10th API version, without any regard to the QEMU version
>> support
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
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 th
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 her
On 6/17/20 3:52 PM, Cleber Rosa wrote:
> On Tue, Jun 02, 2020 at 08:15:16PM -0400, John Snow wrote:
>> Based-on: 20200602214528.12107-1-js...@redhat.com
>>
>> This series factors the python/qemu directory as an installable
>> module. As a developer, you can install this to your virtual environme
On Tue, Jun 02, 2020 at 08:15:16PM -0400, John Snow wrote:
> Based-on: 20200602214528.12107-1-js...@redhat.com
>
> This series factors the python/qemu directory as an installable
> module. As a developer, you can install this to your virtual environment
> and then always have access to the classes
On 6/6/20 1:53 AM, Vladimir Sementsov-Ogievskiy wrote:
> For patches 05-07:
>
> Reviewing such patch is a strange thing: Pipfile changes are obvious
> enough, just select some version (I can't be sure about correct version
> choice, just believe in your commit messages). But what for
> Pipfile.
For patches 05-07:
Reviewing such patch is a strange thing: Pipfile changes are obvious enough,
just select some version (I can't be sure about correct version choice, just
believe in your commit messages). But what for Pipfile.lock? I can state that
it's about package set selecting, Pipfile.l
Based-on: 20200602214528.12107-1-js...@redhat.com
This series factors the python/qemu directory as an installable
module. As a developer, you can install this to your virtual environment
and then always have access to the classes contained within without
needing to wrangle python import path probl
12 matches
Mail list logo
