[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module
From: |
John Snow |
Subject: |
Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module |
Date: |
Wed, 27 May 2020 10:28:44 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
On 5/26/20 11:25 AM, Daniel P. Berrangé wrote:
> On Tue, May 26, 2020 at 05:23:42PM +0200, Philippe Mathieu-Daudé wrote:
>> On 5/26/20 5:22 PM, Daniel P. Berrangé wrote:
>>> On Mon, May 18, 2020 at 08:27:54PM -0400, John Snow wrote:
>>>>
>>>>
>>>> On 5/18/20 3:33 PM, Vladimir Sementsov-Ogievskiy wrote:
>>>>> 18.05.2020 21:23, John Snow wrote:
>>>>>>
>>>>>>
>>>>>> On 5/18/20 2:14 PM, Vladimir Sementsov-Ogievskiy wrote:
>>>>>>> 14.05.2020 08:53, John Snow wrote:
>>>>>>>> move python/qemu/*.py to python/qemu/lib/*.py.
>>>>>>>>
>>>>>>>> To create a namespace package, the 'qemu' directory itself shouldn't
>>>>>>>> have module files in it. Thus, these files will go under a 'lib'
>>>>>>>> package
>>>>>>>> directory instead.
>>>>>>>
>>>>>>> Hmm..
>>>>>>>
>>>>>>> On the first glance, it looks better to have
>>>>>>>
>>>>>>> from qemu import QEMUMachine
>>>>>>>
>>>>>>> than
>>>>>>> from qemu.lib import QEMUMachine
>>>>>>>
>>>>>>> why do we need this extra ".lib" part?
>>>>>>>
>>>>>>> Is it needed only for internal use?
>>>>>>>
>>>>>>> Assume we have installed qemu package. Can we write
>>>>>>>
>>>>>>> from qemu import QEMUMachine
>>>>>>>
>>>>>>> ? Or we still need qemu.lib ?
>>>>>>>
>>>>>>> I don't remember any python package, which made me to write "import from
>>>>>>> package_name.lib ..."
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> It's a strategy to create "qemu" as a PEP420 namespace package; i.e.
>>>>>> "qemu" forms a namespace, but you need a name for the actual package
>>>>>> underneath it.
>>>>>>
>>>>>> "qemu.lib" is one package, with qmp, qtest, and machine modules. "qemu"
>>>>>> isn't really a package in this system, it's just a namespace.
>>>>>>
>>>>>> The idea is that this allows us to create a more modular rollout of
>>>>>> various python scripts and services as desired instead of monolithically
>>>>>> bundling them all inside of a "qemu" package.
>>>>>>
>>>>>> It also allows us to fork or split out the sub-packages to separate
>>>>>> repos, if we wish. i.e., let's say we create a "qemu.sdk" subpackage, we
>>>>>> can eventually fork it off into its own repo with its own installer and
>>>>>> so forth. These subpackages can be installed and managed separately.
>>>>>>
>>>>>
>>>>> Okay, I understand.. No real objections than.
>>>>>
>>>>> Still, maybe, everything should not go into lib, maybe something like
>>>>>
>>>>> qemu/vm/ - qmp, QEMUMachine, etc
>>>>> qemu/qtest/ - qtest
>>>>>
>>>>> would be more user friendly? But I'm not sure. I just thought that "lib"
>>>>> is too generic.
>>>>>
>>>>
>>>> lib is a very generic name, I agree.
>>>>
>>>> Splitting accel, qmp and QEMUMachine in one package and keeping qtest in
>>>> another is fine too. I'm not sure if I like "vm" for the name of that
>>>> core package, though.
>>>>
>>>> I want to avoid using "qemu/sdk" because I have some plans for trying to
>>>> generate and package a "real" SDK using that namespace.
>>>>
>>>> "devkit"? "testkit"? "core"? Naming things is always the worst part.
>>>
>>> I'd suggest "machine", as in
>>>
>>> from qemu.machine import kvm_available, QEMUMachine
>>>
>>> I wouldn't over-think the module naming as it has so little impact on
>>> the code usage - it usually only appears in the "import" statement.
>>
>> Don't forget linux-user binaries.
>
> That's why I suggested ".machine", as all the APIs there currently
> are focused on the machine emulators, and the linx-user binaries
> share essentially nothing in common with softmmu binaries in terms
> of control APIs / CLI config. We can add a "qemu.user" package
> later if we have stuff related to that to expose
>
I'm re-ordering the series to front-load the linting and type-checking;
and the package organization will now come second, in a separate series.
Module naming isn't a big deal right now, but if we package it and
upload to PyPI it will be something we shouldn't change frivolously.
Daniel, are you suggesting we split it like this? --
- qemu.machine (machine.py, qtest.py, accel.py?)
- qemu.monitor (qmp.py)
the only one that's really truly weird is accel.py?, which is just kind
of a misc function. I guess it can go in `qemu.machine` for now and if
we adopt a `qemu.user` later, we can pull it out into a common area if
we need to.
--js
- [PATCH RFC 01/32] python/qemu: create qemu.lib module, (continued)
- [PATCH RFC 01/32] python/qemu: create qemu.lib module, John Snow, 2020/05/14
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Vladimir Sementsov-Ogievskiy, 2020/05/18
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, John Snow, 2020/05/18
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Vladimir Sementsov-Ogievskiy, 2020/05/18
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, John Snow, 2020/05/18
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Vladimir Sementsov-Ogievskiy, 2020/05/19
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Philippe Mathieu-Daudé, 2020/05/26
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Daniel P . Berrangé, 2020/05/26
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Philippe Mathieu-Daudé, 2020/05/26
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Daniel P . Berrangé, 2020/05/26
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module,
John Snow <=
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Daniel P . Berrangé, 2020/05/27
[PATCH RFC 02/32] scripts/qmp: Fix shebang and imports, John Snow, 2020/05/14
[PATCH RFC 03/32] python//machine.py: remove bare except, John Snow, 2020/05/14
Re: [PATCH RFC 03/32] python//machine.py: remove bare except, Philippe Mathieu-Daudé, 2020/05/26
[PATCH RFC 04/32] python/qemu/lib: delint, add pylintrc, John Snow, 2020/05/14