Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module

[Philippe Mathieu-Daudé]

On 5/19/20 12:54 PM, Vladimir Sementsov-Ogievskiy wrote:
> 19.05.2020 03:27, 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

I'm not sure this part is relevant now, as we have not good projection
of what/who/how this package will be consumed.

I suppose by VM you mean VirtualMachine. I find it confusing. Maybe
simply "machine"? We also have 'tools' and 'user-space processes'.

QMP is protocol, common to all. "qemu.core.qmp"?

We also have the gdb(stub) protocol, common to machine(system) & user.

The block layer has its classes, "qemu.block"?

>>>
>>> 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 think, "core" sounds good.

Agreed.