new file mode 100644
@@ -0,0 +1,6 @@
+QEMU Python Tooling
+-------------------
+
+This package provides QEMU tooling used by the QEMU project to build,
+configure, and test QEMU. It is not a fully-fledged SDK and it is subject
+to change at any time.
new file mode 100755
@@ -0,0 +1,50 @@
+#!/usr/bin/env3 python
+"""
+QEMU tooling installer script
+Copyright (c) 2020 John Snow for Red Hat, Inc.
+"""
+
+import setuptools
+
+def main():
+ """
+ QEMU tooling installer
+ """
+
+ kwargs = {
+ 'name': 'qemu',
+ 'use_scm_version': {
+ 'root': '..',
+ 'relative_to': __file__,
+ },
+ 'maintainer': 'QEMU Developer Team',
+ 'maintainer_email': 'qemu-devel@nongnu.org',
+ 'url': 'https://www.qemu.org/',
+ 'download_url': 'https://www.qemu.org/download/',
+ 'packages': setuptools.find_namespace_packages(),
+ 'description': 'QEMU Python Build, Debug and SDK tooling.',
+ 'classifiers': [
+ 'Development Status :: 5 - Production/Stable',
+ 'License :: OSI Approved :: GNU General Public License v2 (GPLv2)',
+ 'Natural Language :: English',
+ 'Operating System :: OS Independent',
+ ],
+ 'platforms': [],
+ 'keywords': [],
+ 'setup_requires': [
+ 'setuptools',
+ 'setuptools_scm',
+ ],
+ 'install_requires': [
+ ],
+ 'python_requires': '>=3.6',
+ 'long_description_content_type': 'text/x-rst',
+ }
+
+ with open("README.rst", "r") as fh:
+ kwargs['long_description'] = fh.read()
+
+ setuptools.setup(**kwargs)
+
+if __name__ == '__main__':
+ main()
NB: I am choosing Python 3.6 here. Although our minimum requirement is 3.5, this code is used only by iotests (so far) under which we have been using a minimum version of 3.6. 3.6 is being preferred here for variable type hint capability, which enables us to use mypy for this package. RFC: This uses the version tags of the parent tree here, so packages will be installed as e.g. 5.0.0, 5.1.0-rc0, etc. Pros: - Easy to tell which versions of QEMU it supports - Simple Cons: - Implies semver, which we do NOT follow for QEMU releases - Implies the package is in a stable state We could also start a separate versioning for just the Python SDK at e.g. 0.1; Pros: - We can use semver, which is expected of Python packaging - Allows us to break compatibility for 0.x releases Cons: - More complex, the mapping from SDK version to QEMU version is less obvious - Requires someone to manage a secondary version commit for the Python SDK. Or, perhaps, we could start versioning with 0.5.0.0, 0.5.1.0, etc to combine a bit of both flavors; bumping the major version number only when incompatible changes to the Python interface itself are made, treating the major version number more like an epoch. Signed-off-by: John Snow <jsnow@redhat.com> --- python/README.rst | 6 ++++++ python/setup.py | 50 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+) create mode 100644 python/README.rst create mode 100755 python/setup.py