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 <js...@redhat.com> Cleber Rosa <cr...@redhat.com> Eduardo Habkost <ehabk...@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
