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

[John Snow]

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.

--js