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.