Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module

[Daniel P . Berrangé]

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 :|