[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module |
Date: |
Tue, 26 May 2020 16:25:51 +0100 |
User-agent: |
Mutt/1.13.4 (2020-02-15) |
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 :|
- [PATCH RFC 00/32] python/qemu: refactor as installable package, John Snow, 2020/05/14
- [PATCH RFC 01/32] python/qemu: create qemu.lib module, John Snow, 2020/05/14
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Vladimir Sementsov-Ogievskiy, 2020/05/18
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, John Snow, 2020/05/18
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Vladimir Sementsov-Ogievskiy, 2020/05/18
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, John Snow, 2020/05/18
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Vladimir Sementsov-Ogievskiy, 2020/05/19
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Philippe Mathieu-Daudé, 2020/05/26
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Daniel P . Berrangé, 2020/05/26
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Philippe Mathieu-Daudé, 2020/05/26
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module,
Daniel P . Berrangé <=
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, John Snow, 2020/05/27
- Re: [PATCH RFC 01/32] python/qemu: create qemu.lib module, Daniel P . Berrangé, 2020/05/27
[PATCH RFC 02/32] scripts/qmp: Fix shebang and imports, John Snow, 2020/05/14
[PATCH RFC 03/32] python//machine.py: remove bare except, John Snow, 2020/05/14
Re: [PATCH RFC 03/32] python//machine.py: remove bare except, Philippe Mathieu-Daudé, 2020/05/26
[PATCH RFC 04/32] python/qemu/lib: delint, add pylintrc, John Snow, 2020/05/14