Publishing Python Packages

Publishing Python Packages

[John Snow]

Hi!

It keeps coming up in review or in bugs that it would be nice to ship
certain python scripts or modules outside of QEMU for easy consumption
as dev tooling, light debugging SDKs, or other various tasks. We keep
avoiding the question as a diversion.

Let's investigate this seriously, but let's keep the scope small. Let's
look at shipping what's in python/qemu/ for starters, as a beta package
-- to explore the space and see what changes are necessary.

Let me start by saying that I have reserved the "qemu" package on
PyPI.org -- I have done so in good faith in order to have a public
discussion about the right way to factor this package -- and can
abdicate my ownership of this package at any point to Peter Maydell,
Eduardo Habkost, etc.

(There is also a conflict resolution process outlined by PEP 541, which
should ensure that I won't be able to maliciously withhold this package
space.)

Here's the package: https://pypi.org/project/qemu/

The only way to 'reserve' a package on pypi is to actually just create
one, so this is a blank package with nothing in it, versioned as low as
you can.

(This blank release can be deleted later, but we can never re-release a
v0.0.0a1 package.)

I'm working on a patchset to "demo" an installable version of what
exists in python/qemu/ right now, but a lot of project structure,
versioning, and layout will have to be debated with a careful list of
pros/cons.

So, for the moment, I am not committing to anything, but am looking
forward to some discussion on the forthcoming patches.

--js

Re: Publishing Python Packages

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]

On Mon, May 04, 2020 at 04:05:18PM -0400, John Snow wrote:
> Hi!
> 
> It keeps coming up in review or in bugs that it would be nice to ship
> certain python scripts or modules outside of QEMU for easy consumption
> as dev tooling, light debugging SDKs, or other various tasks. We keep
> avoiding the question as a diversion.
> 
> Let's investigate this seriously, but let's keep the scope small. Let's
> look at shipping what's in python/qemu/ for starters, as a beta package
> -- to explore the space and see what changes are necessary.
> 
> Let me start by saying that I have reserved the "qemu" package on
> PyPI.org -- I have done so in good faith in order to have a public
> discussion about the right way to factor this package -- and can
> abdicate my ownership of this package at any point to Peter Maydell,
> Eduardo Habkost, etc.
> 
> (There is also a conflict resolution process outlined by PEP 541, which
> should ensure that I won't be able to maliciously withhold this package
> space.)
> 
> Here's the package: https://pypi.org/project/qemu/
> 
> The only way to 'reserve' a package on pypi is to actually just create
> one, so this is a blank package with nothing in it, versioned as low as
> you can.
> 
> (This blank release can be deleted later, but we can never re-release a
> v0.0.0a1 package.)
> 
> I'm working on a patchset to "demo" an installable version of what
> exists in python/qemu/ right now, but a lot of project structure,
> versioning, and layout will have to be debated with a careful list of
> pros/cons.
> 
> So, for the moment, I am not committing to anything, but am looking
> forward to some discussion on the forthcoming patches.

Great, packaging the QEMUMachine and QMP classes would be a useful first
step. These are probably the packages that most users want. It might
even be useful to add libvirt support to the QMP class so that scripts
can either use QEMU directly or libvirt.

A little bit of cleanup may be required, I haven't checked the state of
the code.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]