|
From: | Vladimir Sementsov-Ogievskiy |
Subject: | Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module |
Date: | Tue, 2 Jun 2020 14:15:41 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 |
26.05.2020 18:07, Philippe Mathieu-Daudé wrote:
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/ - qtestI'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"?
Sounds good. But I see now that we shouldn't care too much about this, as we just don't know how it all will be used..
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.
-- Best regards, Vladimir
[Prev in Thread] | Current Thread | [Next in Thread] |