On Tue, May 26, 2020 at 05:23:42PM +0200, Philippe Mathieu-Daudé wrote: > On 5/26/20 5:22 PM, Daniel P. Berrangé wrote: > > 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. > > Don't forget linux-user binaries.
That's why I suggested ".machine", as all the APIs there currently are focused on the machine emulators, and the linx-user binaries share essentially nothing in common with softmmu binaries in terms of control APIs / CLI config. We can add a "qemu.user" package later if we have stuff related to that to expose 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 :|
