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

[Daniel P . Berrangé]

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