[Bug 1874678] Re: [Feature request] python-qemu package

[John Snow]

Hi, Rohit! I am actively involved in pursuing this at the moment. I have
patches that do a lot of this work, but they are not complete and did
not get merged in time for 5.1. I will have to update my development
branches (soon) and share that code.

If you'd like to help, there are three main areas of consideration:

(1) I would like to ensure that all code in ./python/qemu is 100%
pylint/mypy/flake8 compliant. I have many patches for this in
particular. Once it's compliant, we need to prevent regressions: This
task is less well defined in my head. Ideally the package is checked
pythonically (via pytest, perhaps?) as well as via hooks in the QEMU
source tree itself as a `make check-python` style target that can be
checked from e.g. gitlab CI.

For now, the python package will live in the QEMU source tree, so it
needs to function in both contexts simultaneously.

I consider this a requisite for packaging our SDK because it will help
us prevent a certain class of regressions. By smoothing out the API and
its typing in advance, the package will be less turbulent and, if needs
be, easier to refactor with confidence in the future.


(2) The code itself needs packaging glue (setup.py et al.). I also have patches 
here that move ./python/qemu to ./python/qemu/core and installs this as a 
PEP-420 namespace package, 'qemu.core'. The idea was to add different QEMU 
modules over time -- possibly with different dependencies, etc.

One of the ideas is for everything in ./python to be checked using the
same flake8/mypy/pylint regimes for consistency; but if we were to
upload any packages to PyPI, I want to be able to upload them
separately. e.g.

./python/qemu/core ==> PyPI "qemu"
./python/qemu/qapi ==> PyPI "qemu.qapi"

I didn't figure out how facilitate that just yet -- at the moment, any
subpackages present in-tree get uploaded as part of the core API, and
that's not what I wanted to do. Some subpackages we create are going to
be ones we don't want to ever upload to PyPI, but having them in a
standard package form will help with regression testing and development
in-tree.


(3) Versioning is a complex topic and needs some consensus.

- Do we version the subpackages separately, or should they use the parent QEMU 
version?
- Should we release point fixes, or only release alongside official QEMU 
releases?
- How do we indicate beta status? If we release at version 5.2, people might 
expect SDK API stability, but we can't promise that yet!
- QEMU does not use semver, but Python ecosystem largely does. The QEMU 
deprecation policy may not mesh well with Python's expected behavior.

There's a lot there to think about before we push a package to PyPI.
Pushing to PyPI, however, is not a requisite for accomplishing the first
two tasks -- so we can shelf this for a little bit.


If you have some experience with python packaging and distribution and would 
like to help, let me know. You can sign up for the qemu development mailing 
list [1], and send a mail introducing yourself and CC the following folks:

John Snow <jsnow@redhat.com>
Cleber Rosa <crosa@redhat.com>
Eduardo Habkost <ehabkost@redhat.com>

Thanks,
--js


[1] https://lists.gnu.org/mailman/listinfo/qemu-devel

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1874678

Title:
  [Feature request] python-qemu package

Status in QEMU:
  New

Bug description:
  It would be useful to have the python/qemu/ files published as a
  Python pip package, so users from distribution can also use the QEMU
  python methods (in particular for testing) without having to clone the
  full repository.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1874678/+subscriptions