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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|