On Wed, May 27, 2020 at 10:28:44AM -0400, John Snow wrote: > > > On 5/26/20 11:25 AM, Daniel P. Berrangé wrote: > > 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 > > > I'm re-ordering the series to front-load the linting and type-checking; > and the package organization will now come second, in a separate series. > > Module naming isn't a big deal right now, but if we package it and > upload to PyPI it will be something we shouldn't change frivolously. > > Daniel, are you suggesting we split it like this? -- > > - qemu.machine (machine.py, qtest.py, accel.py?) > - qemu.monitor (qmp.py)
I was actually suggesting everything in qemu.machine, but I guess qemu.monitor makes sense, given that this is an interface both for controlling QEMU and the guest agent. > the only one that's really truly weird is accel.py?, which is just kind > of a misc function. I guess it can go in `qemu.machine` for now and if > we adopt a `qemu.user` later, we can pull it out into a common area if > we need to. 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 :|