python/README.rst | 6 + python/qemu/README.rst | 8 + python/Pipfile | 14 ++ python/Pipfile.lock | 195 ++++++++++++++++++++++ python/qemu/__init__.py | 11 -- python/qemu/{ => core}/.flake8 | 0 python/qemu/core/__init__.py | 57 +++++++ python/qemu/{ => core}/accel.py | 0 python/qemu/{ => core}/machine.py | 0 python/qemu/{ => core}/pylintrc | 0 python/qemu/{ => core}/qmp.py | 0 python/qemu/{ => core}/qtest.py | 0 python/setup.py | 50 ++++++ scripts/device-crash-test | 2 +- scripts/qmp/qemu-ga-client | 2 +- scripts/qmp/qmp | 2 +- scripts/qmp/qmp-shell | 2 +- scripts/qmp/qom-fuse | 2 +- scripts/qmp/qom-get | 2 +- scripts/qmp/qom-list | 2 +- scripts/qmp/qom-set | 2 +- scripts/qmp/qom-tree | 2 +- scripts/render_block_graph.py | 6 +- scripts/simplebench/bench_block_job.py | 4 +- tests/acceptance/avocado_qemu/__init__.py | 2 +- tests/acceptance/boot_linux.py | 3 +- tests/acceptance/virtio_check_params.py | 2 +- tests/acceptance/virtio_version.py | 2 +- tests/migration/guestperf/engine.py | 2 +- tests/qemu-iotests/235 | 2 +- tests/qemu-iotests/297 | 2 +- tests/qemu-iotests/iotests.py | 4 +- tests/vm/basevm.py | 6 +- 33 files changed, 355 insertions(+), 39 deletions(-) create mode 100644 python/README.rst create mode 100644 python/qemu/README.rst create mode 100644 python/Pipfile create mode 100644 python/Pipfile.lock delete mode 100644 python/qemu/__init__.py rename python/qemu/{ => core}/.flake8 (100%) create mode 100644 python/qemu/core/__init__.py rename python/qemu/{ => core}/accel.py (100%) rename python/qemu/{ => core}/machine.py (100%) rename python/qemu/{ => core}/pylintrc (100%) rename python/qemu/{ => core}/qmp.py (100%) rename python/qemu/{ => core}/qtest.py (100%) create mode 100755 python/setup.py
Based-on: 20200602214528.12107-1-jsnow@redhat.com This series factors the python/qemu directory as an installable module. As a developer, you can install this to your virtual environment and then always have access to the classes contained within without needing to wrangle python import path problems. When developing, you could go to qemu/python/ and invoke `pipenv shell` to activate a virtual environment within which you could type `pip install -e .` to install a special development version of this package to your virtual environment. This package will always reflect the most recent version of the source files in the tree. When not developing, you could install a version of this package to your environment outright to gain access to the QMP and QEMUMachine classes for lightweight scripting and testing. This package is formatted in such a way that it COULD be uploaded to https://pypi.org/project/qemu and installed independently of qemu.git with `pip install qemu`, but of course that button remains unpushed. There are a few major questions to answer first: - What versioning scheme should we use? See patch 2. - Should we use a namespace package or not? - Namespaced: 'qemu.machine', 'qemu.monitor' etc may be separately versioned, packaged and distributed packages. Third party authors may register 'qemu.xxx' to create plugins within the namespace as they see fit. - Non-namespaced: 'qemu' is one giant glob package, packaged and versioned in unison. We control this package exclusively. - How do we eliminate sys.path hacks from the rest of the QEMU tree? (Background: sys.path hacks generally impede the function of static code quality analysis tools like mypy and pylint.) - Simplest: parent scripts (or developer) needs to set PYTHONPATH. - Harder: Python scripts should all be written to assume package form, all tests and CI that use Python should execute within a VENV. In either case, we lose the ability (for many scripts) to "just run" a script out of the source tree if it depends on other QEMU Python files. This is annoying, but as the complexity of the Python lib grows, it is unavoidable. In the VENV case, we at least establish a simple paradigm: the scripts should work in their "installed" forms; and the rest of the build and test infrastructure should use this VENV to automatically handle dependencies and path requirements. This should allow us to move many of our existing python scripts with "hidden" dependencies into a proper python module hierarchy and test for regressions with mypy, flake8, pylint, etc. (We could even establish e.g. Sphinx versions as a dependency for our build kit here and make sure it's installed to the VENV.) Pros: Almost all scripts can be moved under python/qemu/* and checked with CQA tools. imports are written the same no matter where you are (Use the fully qualified names, e.g. qemu.core.qmp.QMPMessage). Regressions in scripts are caught *much* faster. Downsides: Kind of annoying; most scripts now require you to install a devkit forwarder (pip3 install --user .) or be inside of an activated venv. Not too bad if you know python at all, but it's certainly less plug-n-play. - What's our backwards compatibility policy if we start shipping this? Proposed: Attempt to maintain API compatibility (after stabilizing the library). Incompatible changes should probably cause a semver bump. Each published release makes no attempt to support any version of QEMU other than the one it was released against. We publish this on the tin in big red letters. TESTING THIS PACKAGE OUT: 1. You can install to your local user's environment normally by navigating to qemu/python/ and typing "pip3 install --user ." 2. If you are in a VENV, use "pip install ." 3. To install in development mode (Where the installed package always reflects the most recent version of the files automatically), use "pip3 install -e ." or "pip install -e ." as appropriate (See above) John Snow (7): python/qemu: create qemu.lib module python/qemu: formalize as package python/qemu: add README.rst python/qemu: Add pipenv support python/qemu: add pylint to pipenv python/qemu: Add flake8 to pipenv python/qemu: add mypy to pipenv python/README.rst | 6 + python/qemu/README.rst | 8 + python/Pipfile | 14 ++ python/Pipfile.lock | 195 ++++++++++++++++++++++ python/qemu/__init__.py | 11 -- python/qemu/{ => core}/.flake8 | 0 python/qemu/core/__init__.py | 57 +++++++ python/qemu/{ => core}/accel.py | 0 python/qemu/{ => core}/machine.py | 0 python/qemu/{ => core}/pylintrc | 0 python/qemu/{ => core}/qmp.py | 0 python/qemu/{ => core}/qtest.py | 0 python/setup.py | 50 ++++++ scripts/device-crash-test | 2 +- scripts/qmp/qemu-ga-client | 2 +- scripts/qmp/qmp | 2 +- scripts/qmp/qmp-shell | 2 +- scripts/qmp/qom-fuse | 2 +- scripts/qmp/qom-get | 2 +- scripts/qmp/qom-list | 2 +- scripts/qmp/qom-set | 2 +- scripts/qmp/qom-tree | 2 +- scripts/render_block_graph.py | 6 +- scripts/simplebench/bench_block_job.py | 4 +- tests/acceptance/avocado_qemu/__init__.py | 2 +- tests/acceptance/boot_linux.py | 3 +- tests/acceptance/virtio_check_params.py | 2 +- tests/acceptance/virtio_version.py | 2 +- tests/migration/guestperf/engine.py | 2 +- tests/qemu-iotests/235 | 2 +- tests/qemu-iotests/297 | 2 +- tests/qemu-iotests/iotests.py | 4 +- tests/vm/basevm.py | 6 +- 33 files changed, 355 insertions(+), 39 deletions(-) create mode 100644 python/README.rst create mode 100644 python/qemu/README.rst create mode 100644 python/Pipfile create mode 100644 python/Pipfile.lock delete mode 100644 python/qemu/__init__.py rename python/qemu/{ => core}/.flake8 (100%) create mode 100644 python/qemu/core/__init__.py rename python/qemu/{ => core}/accel.py (100%) rename python/qemu/{ => core}/machine.py (100%) rename python/qemu/{ => core}/pylintrc (100%) rename python/qemu/{ => core}/qmp.py (100%) rename python/qemu/{ => core}/qtest.py (100%) create mode 100755 python/setup.py -- 2.21.3
For patches 05-07: Reviewing such patch is a strange thing: Pipfile changes are obvious enough, just select some version (I can't be sure about correct version choice, just believe in your commit messages). But what for Pipfile.lock? I can state that it's about package set selecting, Pipfile.lock looks like what it should be, but I have idea about all these packages, their versions and hashes (and even, does it correspond really to Pipfile or not) :) Ha, what I can check, is: does pipenv create almost same Pipfile.lock in my environment (with 3.7.5 python) OK, I've tried (pipenv lock --dev --python /usr/bin/python3), and yes, result is almost the same. For mypy and importlib-metadata packages I have newer version and different hashes (of course). Other packages are the same. Set of packages is the same. Hmm, but in may generated Pipfile.lock there no "markers". They are about python version and looks like "markers": "python_version >= '3.5'".. Does pipenv follow them? Then why they are not generated for me, did you use some additional command/option to create them? Anyway, they don't look dangerous, so for last three patches: Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 03.06.2020 03:15, John Snow wrote: > Based-on: 20200602214528.12107-1-jsnow@redhat.com > > This series factors the python/qemu directory as an installable > module. As a developer, you can install this to your virtual environment > and then always have access to the classes contained within without > needing to wrangle python import path problems. > > When developing, you could go to qemu/python/ and invoke `pipenv shell` > to activate a virtual environment within which you could type `pip > install -e .` to install a special development version of this package > to your virtual environment. This package will always reflect the most > recent version of the source files in the tree. > > When not developing, you could install a version of this package to your > environment outright to gain access to the QMP and QEMUMachine classes > for lightweight scripting and testing. > > This package is formatted in such a way that it COULD be uploaded to > https://pypi.org/project/qemu and installed independently of qemu.git > with `pip install qemu`, but of course that button remains unpushed. > > There are a few major questions to answer first: > > - What versioning scheme should we use? See patch 2. > > - Should we use a namespace package or not? > - Namespaced: 'qemu.machine', 'qemu.monitor' etc may be separately > versioned, packaged and distributed packages. Third party authors > may register 'qemu.xxx' to create plugins within the namespace as > they see fit. > > - Non-namespaced: 'qemu' is one giant glob package, packaged and > versioned in unison. We control this package exclusively. > > - How do we eliminate sys.path hacks from the rest of the QEMU tree? > (Background: sys.path hacks generally impede the function of static > code quality analysis tools like mypy and pylint.) > > - Simplest: parent scripts (or developer) needs to set PYTHONPATH. > > - Harder: Python scripts should all be written to assume package form, > all tests and CI that use Python should execute within a VENV. > > In either case, we lose the ability (for many scripts) to "just run" a > script out of the source tree if it depends on other QEMU Python > files. This is annoying, but as the complexity of the Python lib > grows, it is unavoidable. > > In the VENV case, we at least establish a simple paradigm: the scripts > should work in their "installed" forms; and the rest of the build and > test infrastructure should use this VENV to automatically handle > dependencies and path requirements. This should allow us to move many > of our existing python scripts with "hidden" dependencies into a > proper python module hierarchy and test for regressions with mypy, > flake8, pylint, etc. > > (We could even establish e.g. Sphinx versions as a dependency for our > build kit here and make sure it's installed to the VENV.) > > Pros: Almost all scripts can be moved under python/qemu/* and checked > with CQA tools. imports are written the same no matter where you are > (Use the fully qualified names, e.g. qemu.core.qmp.QMPMessage). > Regressions in scripts are caught *much* faster. > > Downsides: Kind of annoying; most scripts now require you to install a > devkit forwarder (pip3 install --user .) or be inside of an activated > venv. Not too bad if you know python at all, but it's certainly less > plug-n-play. > > - What's our backwards compatibility policy if we start shipping this? > > Proposed: Attempt to maintain API compatibility (after stabilizing the > library). Incompatible changes should probably cause a semver bump. > > Each published release makes no attempt to support any version of QEMU > other than the one it was released against. We publish this on the tin > in big red letters. > > TESTING THIS PACKAGE OUT: > > 1. You can install to your local user's environment normally by > navigating to qemu/python/ and typing "pip3 install --user ." > > 2. If you are in a VENV, use "pip install ." > > 3. To install in development mode (Where the installed package always > reflects the most recent version of the files automatically), use "pip3 > install -e ." or "pip install -e ." as appropriate (See above) > > John Snow (7): > python/qemu: create qemu.lib module > python/qemu: formalize as package > python/qemu: add README.rst > python/qemu: Add pipenv support > python/qemu: add pylint to pipenv > python/qemu: Add flake8 to pipenv > python/qemu: add mypy to pipenv > > python/README.rst | 6 + > python/qemu/README.rst | 8 + > python/Pipfile | 14 ++ > python/Pipfile.lock | 195 ++++++++++++++++++++++ > python/qemu/__init__.py | 11 -- > python/qemu/{ => core}/.flake8 | 0 > python/qemu/core/__init__.py | 57 +++++++ > python/qemu/{ => core}/accel.py | 0 > python/qemu/{ => core}/machine.py | 0 > python/qemu/{ => core}/pylintrc | 0 > python/qemu/{ => core}/qmp.py | 0 > python/qemu/{ => core}/qtest.py | 0 > python/setup.py | 50 ++++++ > scripts/device-crash-test | 2 +- > scripts/qmp/qemu-ga-client | 2 +- > scripts/qmp/qmp | 2 +- > scripts/qmp/qmp-shell | 2 +- > scripts/qmp/qom-fuse | 2 +- > scripts/qmp/qom-get | 2 +- > scripts/qmp/qom-list | 2 +- > scripts/qmp/qom-set | 2 +- > scripts/qmp/qom-tree | 2 +- > scripts/render_block_graph.py | 6 +- > scripts/simplebench/bench_block_job.py | 4 +- > tests/acceptance/avocado_qemu/__init__.py | 2 +- > tests/acceptance/boot_linux.py | 3 +- > tests/acceptance/virtio_check_params.py | 2 +- > tests/acceptance/virtio_version.py | 2 +- > tests/migration/guestperf/engine.py | 2 +- > tests/qemu-iotests/235 | 2 +- > tests/qemu-iotests/297 | 2 +- > tests/qemu-iotests/iotests.py | 4 +- > tests/vm/basevm.py | 6 +- > 33 files changed, 355 insertions(+), 39 deletions(-) > create mode 100644 python/README.rst > create mode 100644 python/qemu/README.rst > create mode 100644 python/Pipfile > create mode 100644 python/Pipfile.lock > delete mode 100644 python/qemu/__init__.py > rename python/qemu/{ => core}/.flake8 (100%) > create mode 100644 python/qemu/core/__init__.py > rename python/qemu/{ => core}/accel.py (100%) > rename python/qemu/{ => core}/machine.py (100%) > rename python/qemu/{ => core}/pylintrc (100%) > rename python/qemu/{ => core}/qmp.py (100%) > rename python/qemu/{ => core}/qtest.py (100%) > create mode 100755 python/setup.py > -- Best regards, Vladimir
On 6/6/20 1:53 AM, Vladimir Sementsov-Ogievskiy wrote: > For patches 05-07: > > Reviewing such patch is a strange thing: Pipfile changes are obvious > enough, just select some version (I can't be sure about correct version > choice, just believe in your commit messages). But what for > Pipfile.lock? I can state that it's about package set selecting, > Pipfile.lock looks like what it should be, but I have idea about all > these packages, their versions and hashes (and even, does it correspond > really to Pipfile or not) :) > > Ha, what I can check, is: does pipenv create almost same Pipfile.lock in > my environment (with 3.7.5 python) > OK, I've tried (pipenv lock --dev --python /usr/bin/python3), and yes, > result is almost the same. For mypy and importlib-metadata packages I > have newer version and different hashes (of course). Other packages are > the same. Set of packages is the same. > > Hmm, but in may generated Pipfile.lock there no "markers". They are > about python version and looks like "markers": "python_version >= > '3.5'".. Does pipenv follow them? Then why they are not generated for > me, did you use some additional command/option to create them? > Anyway, they don't look dangerous, so for last three patches: > Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > Yes, from a blank repository you can do "pipenv install mypy>=0.730" -- it uses the same package specification syntax that pip uses. (Or, you can edit the Pipfile manually, which is what I actually did. The benefit of doing so is primarily about documenting our minimum version requirements. I suppose in truth, those minimums should go into setup.py too, actually.) Thanks for taking a look! --js > 03.06.2020 03:15, John Snow wrote: >> Based-on: 20200602214528.12107-1-jsnow@redhat.com >> >> This series factors the python/qemu directory as an installable >> module. As a developer, you can install this to your virtual environment >> and then always have access to the classes contained within without >> needing to wrangle python import path problems. >> >> When developing, you could go to qemu/python/ and invoke `pipenv shell` >> to activate a virtual environment within which you could type `pip >> install -e .` to install a special development version of this package >> to your virtual environment. This package will always reflect the most >> recent version of the source files in the tree. >> >> When not developing, you could install a version of this package to your >> environment outright to gain access to the QMP and QEMUMachine classes >> for lightweight scripting and testing. >> >> This package is formatted in such a way that it COULD be uploaded to >> https://pypi.org/project/qemu and installed independently of qemu.git >> with `pip install qemu`, but of course that button remains unpushed. >> >> There are a few major questions to answer first: >> >> - What versioning scheme should we use? See patch 2. >> >> - Should we use a namespace package or not? >> - Namespaced: 'qemu.machine', 'qemu.monitor' etc may be separately >> versioned, packaged and distributed packages. Third party authors >> may register 'qemu.xxx' to create plugins within the namespace as >> they see fit. >> >> - Non-namespaced: 'qemu' is one giant glob package, packaged and >> versioned in unison. We control this package exclusively. >> >> - How do we eliminate sys.path hacks from the rest of the QEMU tree? >> (Background: sys.path hacks generally impede the function of static >> code quality analysis tools like mypy and pylint.) >> >> - Simplest: parent scripts (or developer) needs to set PYTHONPATH. >> >> - Harder: Python scripts should all be written to assume package form, >> all tests and CI that use Python should execute within a VENV. >> >> In either case, we lose the ability (for many scripts) to "just run" a >> script out of the source tree if it depends on other QEMU Python >> files. This is annoying, but as the complexity of the Python lib >> grows, it is unavoidable. >> >> In the VENV case, we at least establish a simple paradigm: the scripts >> should work in their "installed" forms; and the rest of the build and >> test infrastructure should use this VENV to automatically handle >> dependencies and path requirements. This should allow us to move many >> of our existing python scripts with "hidden" dependencies into a >> proper python module hierarchy and test for regressions with mypy, >> flake8, pylint, etc. >> >> (We could even establish e.g. Sphinx versions as a dependency for our >> build kit here and make sure it's installed to the VENV.) >> >> Pros: Almost all scripts can be moved under python/qemu/* and checked >> with CQA tools. imports are written the same no matter where you are >> (Use the fully qualified names, e.g. qemu.core.qmp.QMPMessage). >> Regressions in scripts are caught *much* faster. >> >> Downsides: Kind of annoying; most scripts now require you to install a >> devkit forwarder (pip3 install --user .) or be inside of an activated >> venv. Not too bad if you know python at all, but it's certainly less >> plug-n-play. >> >> - What's our backwards compatibility policy if we start shipping this? >> >> Proposed: Attempt to maintain API compatibility (after stabilizing the >> library). Incompatible changes should probably cause a semver bump. >> >> Each published release makes no attempt to support any version of QEMU >> other than the one it was released against. We publish this on the tin >> in big red letters. >> >> TESTING THIS PACKAGE OUT: >> >> 1. You can install to your local user's environment normally by >> navigating to qemu/python/ and typing "pip3 install --user ." >> >> 2. If you are in a VENV, use "pip install ." >> >> 3. To install in development mode (Where the installed package always >> reflects the most recent version of the files automatically), use "pip3 >> install -e ." or "pip install -e ." as appropriate (See above) >> >> John Snow (7): >> python/qemu: create qemu.lib module >> python/qemu: formalize as package >> python/qemu: add README.rst >> python/qemu: Add pipenv support >> python/qemu: add pylint to pipenv >> python/qemu: Add flake8 to pipenv >> python/qemu: add mypy to pipenv >> >> python/README.rst | 6 + >> python/qemu/README.rst | 8 + >> python/Pipfile | 14 ++ >> python/Pipfile.lock | 195 ++++++++++++++++++++++ >> python/qemu/__init__.py | 11 -- >> python/qemu/{ => core}/.flake8 | 0 >> python/qemu/core/__init__.py | 57 +++++++ >> python/qemu/{ => core}/accel.py | 0 >> python/qemu/{ => core}/machine.py | 0 >> python/qemu/{ => core}/pylintrc | 0 >> python/qemu/{ => core}/qmp.py | 0 >> python/qemu/{ => core}/qtest.py | 0 >> python/setup.py | 50 ++++++ >> scripts/device-crash-test | 2 +- >> scripts/qmp/qemu-ga-client | 2 +- >> scripts/qmp/qmp | 2 +- >> scripts/qmp/qmp-shell | 2 +- >> scripts/qmp/qom-fuse | 2 +- >> scripts/qmp/qom-get | 2 +- >> scripts/qmp/qom-list | 2 +- >> scripts/qmp/qom-set | 2 +- >> scripts/qmp/qom-tree | 2 +- >> scripts/render_block_graph.py | 6 +- >> scripts/simplebench/bench_block_job.py | 4 +- >> tests/acceptance/avocado_qemu/__init__.py | 2 +- >> tests/acceptance/boot_linux.py | 3 +- >> tests/acceptance/virtio_check_params.py | 2 +- >> tests/acceptance/virtio_version.py | 2 +- >> tests/migration/guestperf/engine.py | 2 +- >> tests/qemu-iotests/235 | 2 +- >> tests/qemu-iotests/297 | 2 +- >> tests/qemu-iotests/iotests.py | 4 +- >> tests/vm/basevm.py | 6 +- >> 33 files changed, 355 insertions(+), 39 deletions(-) >> create mode 100644 python/README.rst >> create mode 100644 python/qemu/README.rst >> create mode 100644 python/Pipfile >> create mode 100644 python/Pipfile.lock >> delete mode 100644 python/qemu/__init__.py >> rename python/qemu/{ => core}/.flake8 (100%) >> create mode 100644 python/qemu/core/__init__.py >> rename python/qemu/{ => core}/accel.py (100%) >> rename python/qemu/{ => core}/machine.py (100%) >> rename python/qemu/{ => core}/pylintrc (100%) >> rename python/qemu/{ => core}/qmp.py (100%) >> rename python/qemu/{ => core}/qtest.py (100%) >> create mode 100755 python/setup.py >> > > -- —js
On Tue, Jun 02, 2020 at 08:15:16PM -0400, John Snow wrote: > Based-on: 20200602214528.12107-1-jsnow@redhat.com > > This series factors the python/qemu directory as an installable > module. As a developer, you can install this to your virtual environment > and then always have access to the classes contained within without > needing to wrangle python import path problems. > First of all, major kudos for picking up this task. It's so high in importance to so many users (myself included) that I feel like I owe you many truck loads of beers now. :) > When developing, you could go to qemu/python/ and invoke `pipenv shell` > to activate a virtual environment within which you could type `pip > install -e .` to install a special development version of this package > to your virtual environment. This package will always reflect the most > recent version of the source files in the tree. > > When not developing, you could install a version of this package to your > environment outright to gain access to the QMP and QEMUMachine classes > for lightweight scripting and testing. > > This package is formatted in such a way that it COULD be uploaded to > https://pypi.org/project/qemu and installed independently of qemu.git > with `pip install qemu`, but of course that button remains unpushed. > > There are a few major questions to answer first: > > - What versioning scheme should we use? See patch 2. > > - Should we use a namespace package or not? > - Namespaced: 'qemu.machine', 'qemu.monitor' etc may be separately > versioned, packaged and distributed packages. Third party authors > may register 'qemu.xxx' to create plugins within the namespace as > they see fit. > > - Non-namespaced: 'qemu' is one giant glob package, packaged and > versioned in unison. We control this package exclusively. > For simplicity sake, I'd suggest starting with non-namespaced approach. It should be easier to move to a namespaced package if the need arises. Also, there are many ways to extend Python code without necessarily requiring third party authors to register their packages according to a namespace. In the Avocado project, we have been using setuptools entrypoints with a reasonable level of success. Anyone can have code under any namespace whatsoever extending Avocado, as long as it register their entrypoints. > - How do we eliminate sys.path hacks from the rest of the QEMU tree? > (Background: sys.path hacks generally impede the function of static > code quality analysis tools like mypy and pylint.) > > - Simplest: parent scripts (or developer) needs to set PYTHONPATH. > > - Harder: Python scripts should all be written to assume package form, > all tests and CI that use Python should execute within a VENV. > Having a venv is desirable, but it's not really necessary. As long as "python setup.py develop --user" is called, that user can access this code without sys.path hacks. And if the user chooses to use a venv, it's just an extra step. In the Avocado project, we have a `make develop` rule that does that for the main setup.py file, and for all plugins we carry on the same tree, which is similar in some regards to the "not at the project root directory" situation here with "qemu/python/setup.py". > In either case, we lose the ability (for many scripts) to "just run" a > script out of the source tree if it depends on other QEMU Python > files. This is annoying, but as the complexity of the Python lib > grows, it is unavoidable. > Like I said before, we may introduce a "make develop"-like requirement, but after that, I don't think we'll loose anything. Also, I think this is just a sign of maturity. We should be using Python as it's inteded to be used, and sys.path hacks is not among those. > In the VENV case, we at least establish a simple paradigm: the scripts > should work in their "installed" forms; and the rest of the build and > test infrastructure should use this VENV to automatically handle > dependencies and path requirements. This should allow us to move many > of our existing python scripts with "hidden" dependencies into a > proper python module hierarchy and test for regressions with mypy, > flake8, pylint, etc. > > (We could even establish e.g. Sphinx versions as a dependency for our > build kit here and make sure it's installed to the VENV.) > > Pros: Almost all scripts can be moved under python/qemu/* and checked > with CQA tools. imports are written the same no matter where you are > (Use the fully qualified names, e.g. qemu.core.qmp.QMPMessage). > Regressions in scripts are caught *much* faster. > > Downsides: Kind of annoying; most scripts now require you to install a > devkit forwarder (pip3 install --user .) or be inside of an activated > venv. Not too bad if you know python at all, but it's certainly less > plug-n-play. > > - What's our backwards compatibility policy if we start shipping this? > > Proposed: Attempt to maintain API compatibility (after stabilizing the > library). Incompatible changes should probably cause a semver bump. > > Each published release makes no attempt to support any version of QEMU > other than the one it was released against. We publish this on the tin > in big red letters. It may be too early to tell, but it's not clear to me how we'll keep both the QEMU version supported by a given release, and its API "level". Are you proposing that we have, say, "python-qemu" version 10, being the 10th API version, without any regard to the QEMU version supported? Or version 10.5.3 would mean 10th API version, intended to support QEMU 5.3? > > TESTING THIS PACKAGE OUT: > > 1. You can install to your local user's environment normally by > navigating to qemu/python/ and typing "pip3 install --user ." > s/install/develop/ should be a better option here. I mean, I'm not aware of any reason to user install while developing. - Cleber.
On 6/17/20 3:52 PM, Cleber Rosa wrote: > On Tue, Jun 02, 2020 at 08:15:16PM -0400, John Snow wrote: >> Based-on: 20200602214528.12107-1-jsnow@redhat.com >> >> This series factors the python/qemu directory as an installable >> module. As a developer, you can install this to your virtual environment >> and then always have access to the classes contained within without >> needing to wrangle python import path problems. >> > > First of all, major kudos for picking up this task. It's so high in > importance to so many users (myself included) that I feel like I owe > you many truck loads of beers now. :) > Mostly I just wanted to formalize mypy, pylint, flake8 et al across the most important python bits in our tree so that when making changes for testing it's easier to verify that I didn't break something else. Easiest way to get the right structure that these tools expect is to make a real package ... So here we are. And also Philippe asked nicely. >> When developing, you could go to qemu/python/ and invoke `pipenv shell` >> to activate a virtual environment within which you could type `pip >> install -e .` to install a special development version of this package >> to your virtual environment. This package will always reflect the most >> recent version of the source files in the tree. >> >> When not developing, you could install a version of this package to your >> environment outright to gain access to the QMP and QEMUMachine classes >> for lightweight scripting and testing. >> >> This package is formatted in such a way that it COULD be uploaded to >> https://pypi.org/project/qemu and installed independently of qemu.git >> with `pip install qemu`, but of course that button remains unpushed. >> >> There are a few major questions to answer first: >> >> - What versioning scheme should we use? See patch 2. >> >> - Should we use a namespace package or not? >> - Namespaced: 'qemu.machine', 'qemu.monitor' etc may be separately >> versioned, packaged and distributed packages. Third party authors >> may register 'qemu.xxx' to create plugins within the namespace as >> they see fit. >> >> - Non-namespaced: 'qemu' is one giant glob package, packaged and >> versioned in unison. We control this package exclusively. >> > > For simplicity sake, I'd suggest starting with non-namespaced > approach. It should be easier to move to a namespaced package if the > need arises. Also, there are many ways to extend Python code without > necessarily requiring third party authors to register their packages > according to a namespace. > > In the Avocado project, we have been using setuptools entrypoints with > a reasonable level of success. Anyone can have code under any > namespace whatsoever extending Avocado, as long as it register their > entrypoints. > It's not (from my POV) very complex to do a namespace. I have some plans to move e.g. qapi into qemu.qapi, and some of our other tools into qemu.tools. Some of these packages can be published externally, some can remain in the tree. but -- maybe namespaces ARE complicating matters in ways I don't understand yet. I'll be open about it. The thought was mostly about keeping flexibility with just installing the bits and pieces that you want/need. >> - How do we eliminate sys.path hacks from the rest of the QEMU tree? >> (Background: sys.path hacks generally impede the function of static >> code quality analysis tools like mypy and pylint.) >> >> - Simplest: parent scripts (or developer) needs to set PYTHONPATH. >> >> - Harder: Python scripts should all be written to assume package form, >> all tests and CI that use Python should execute within a VENV. >> > > Having a venv is desirable, but it's not really necessary. As long as > "python setup.py develop --user" is called, that user can access this > code without sys.path hacks. And if the user chooses to use a venv, > it's just an extra step. > whether a venv or a user installation, it's the same thing, really: the user needs to set up and be in that environment to use the python tools in the tree. Once we're there, we may as well formalize the VENV to make it easier to set up and use. > In the Avocado project, we have a `make develop` rule that does that > for the main setup.py file, and for all plugins we carry on the same > tree, which is similar in some regards to the "not at the project root > directory" situation here with "qemu/python/setup.py". > Ah, yeah. If we're going this far, I'd prefer using a VENV over modifying the user's environment. That way you can blast it all away with a `make distclean`. Maybe the "make develop" target could even use the presence of a .venv directory to know when it needs to make the environment or not ... >> In either case, we lose the ability (for many scripts) to "just run" a >> script out of the source tree if it depends on other QEMU Python >> files. This is annoying, but as the complexity of the Python lib >> grows, it is unavoidable. >> > > Like I said before, we may introduce a "make develop"-like > requirement, but after that, I don't think we'll loose anything. > Also, I think this is just a sign of maturity. We should be using > Python as it's inteded to be used, and sys.path hacks is not among > those. > Joking nitpick: There is no intended way to use Python! :) Still, the sys.path hacks -- worse than being "unpythonic", actively seem to get in the way of pylint, flake8, mypy et al which do provide us with legitimate and serious value. So, sad to say, but we might lose the ability to run these python scripts ad-hoc out of the tree (with no setup) in order to gain a more robust python CI regime. I think it's a fair trade-off, but we'll see if that's born out in review. >> In the VENV case, we at least establish a simple paradigm: the scripts >> should work in their "installed" forms; and the rest of the build and >> test infrastructure should use this VENV to automatically handle >> dependencies and path requirements. This should allow us to move many >> of our existing python scripts with "hidden" dependencies into a >> proper python module hierarchy and test for regressions with mypy, >> flake8, pylint, etc. >> >> (We could even establish e.g. Sphinx versions as a dependency for our >> build kit here and make sure it's installed to the VENV.) >> >> Pros: Almost all scripts can be moved under python/qemu/* and checked >> with CQA tools. imports are written the same no matter where you are >> (Use the fully qualified names, e.g. qemu.core.qmp.QMPMessage). >> Regressions in scripts are caught *much* faster. >> >> Downsides: Kind of annoying; most scripts now require you to install a >> devkit forwarder (pip3 install --user .) or be inside of an activated >> venv. Not too bad if you know python at all, but it's certainly less >> plug-n-play. >> >> - What's our backwards compatibility policy if we start shipping this? >> >> Proposed: Attempt to maintain API compatibility (after stabilizing the >> library). Incompatible changes should probably cause a semver bump. >> >> Each published release makes no attempt to support any version of QEMU >> other than the one it was released against. We publish this on the tin >> in big red letters. > > It may be too early to tell, but it's not clear to me how we'll keep > both the QEMU version supported by a given release, and its API > "level". > > Are you proposing that we have, say, "python-qemu" version 10, being > the 10th API version, without any regard to the QEMU version > supported? Or version 10.5.3 would mean 10th API version, intended > to support QEMU 5.3? > I am proposing only that we use semver to track the API version of the SDK itself. So that could be: A) 1.x, 2.x, 3.x (etc) with absolutely no connection to the intended QEMU support version. It either works or it doesn't. It might not work very spectacularly. Major semver bumps indicate a breaking change to the library API. B) 1.5.0.0, 1.5.1.0, 1.5.2.0 (etc) where the major version still describes the API, but the remainder of the version describes the intended target QEMU. Or, we could do: C) 5.0.0, 5.1.0, 5.2.0, etc. where it tracks the QEMU version verbatim, end of story. I don't like (C) very much, because it violates some prevailing idioms about python package versioning. A or B seem better, but do run us into potential trouble with people having mismatched versions. I'd take A or B. (B) is a little chatty but gives some good information and allows you to pin versions effectively, so I think I'm leaning towards that one right now. Well, whatever we do right now, I think I do really want to make sure we are publishing under 0.x to really give the illustration that we are NOT promising even the illusion of stability right now. >> >> TESTING THIS PACKAGE OUT: >> >> 1. You can install to your local user's environment normally by >> navigating to qemu/python/ and typing "pip3 install --user ." >> > > s/install/develop/ should be a better option here. I mean, I'm > not aware of any reason to user install while developing. > I tried to make note to the develop case in several places; for the purposes of this email I wanted to demonstrate what installing and using it as a user would look like. For those unaware of the distinction: - install does a real bona-fide installation. - develop installs a forwarder package that references the living development files, so the package contents (but NOT its metadata!) are always up to date with your development files. For QEMU developers, installing with develop is going to be the smart way to go. When your git tree is updated, your package will be updated along with it. You can do it once and then probably forget about it. > - Cleber. >
Am 17.06.2020 um 22:27 hat John Snow geschrieben: > > In the Avocado project, we have a `make develop` rule that does that > > for the main setup.py file, and for all plugins we carry on the same > > tree, which is similar in some regards to the "not at the project root > > directory" situation here with "qemu/python/setup.py". > > > > Ah, yeah. If we're going this far, I'd prefer using a VENV over > modifying the user's environment. That way you can blast it all away > with a `make distclean`. > > Maybe the "make develop" target could even use the presence of a .venv > directory to know when it needs to make the environment or not ... [..] > For QEMU developers, installing with develop is going to be the smart > way to go. When your git tree is updated, your package will be updated > along with it. You can do it once and then probably forget about it. I don't think we can make this a manual step at all. Building QEMU requires running some Python scripts (e.g. the QAPI generator), so the setup needs to be done either in configure or in a Makefile target that is specified as a dependency of any rule that would run a Python script. Building QEMU once would then be enough. Doing it automatically also means that we have to keep things local to the QEMU directory rather than installing them globally into the user directory. This is desirable anyway: Most of us deal with more than one QEMU source tree, so conflicts would be inevitable. Kevin
On 6/18/20 5:23 AM, Kevin Wolf wrote: > Am 17.06.2020 um 22:27 hat John Snow geschrieben: >>> In the Avocado project, we have a `make develop` rule that does that >>> for the main setup.py file, and for all plugins we carry on the same >>> tree, which is similar in some regards to the "not at the project root >>> directory" situation here with "qemu/python/setup.py". >>> >> >> Ah, yeah. If we're going this far, I'd prefer using a VENV over >> modifying the user's environment. That way you can blast it all away >> with a `make distclean`. >> >> Maybe the "make develop" target could even use the presence of a .venv >> directory to know when it needs to make the environment or not ... > [..] >> For QEMU developers, installing with develop is going to be the smart >> way to go. When your git tree is updated, your package will be updated >> along with it. You can do it once and then probably forget about it. > > I don't think we can make this a manual step at all. Building QEMU > requires running some Python scripts (e.g. the QAPI generator), so the > setup needs to be done either in configure or in a Makefile target that > is specified as a dependency of any rule that would run a Python script. > Building QEMU once would then be enough. > I am imagining that we might treat "building" and "testing" separately -- as it is, builds require python3.5 and tests requires 3.6 which definitely necessitates two distinct environments. I will admit that I haven't constructed a full, coherent vision of python management that encapsulates both building ad testing yet. For example, should configure/make expect to be run inside of a venv, or should they expect to create and then enter the venv? That's not clear to me yet. I'm simultaneously trying to work out with Peter Maydell how the sphinx dependency should work. Sphinx is presently our only python dependency for our build environment.) Perhaps starting with the testing step is a good starting point and we can use an implicit dependency on a `make develop` style step so it happens automatically. (But perhaps keeping it as a standalone target that CAN be invoked manually would be nice if you want to do some more intensive debugging or development of new tests.) > Doing it automatically also means that we have to keep things local to > the QEMU directory rather than installing them globally into the user > directory. This is desirable anyway: Most of us deal with more than one > QEMU source tree, so conflicts would be inevitable. > I think it should be easy enough to put the VENV in the build directory to prevent cross-contamination. > Kevin >
Am 19.06.2020 um 17:04 hat John Snow geschrieben: > On 6/18/20 5:23 AM, Kevin Wolf wrote: > > Am 17.06.2020 um 22:27 hat John Snow geschrieben: > >>> In the Avocado project, we have a `make develop` rule that does that > >>> for the main setup.py file, and for all plugins we carry on the same > >>> tree, which is similar in some regards to the "not at the project root > >>> directory" situation here with "qemu/python/setup.py". > >>> > >> > >> Ah, yeah. If we're going this far, I'd prefer using a VENV over > >> modifying the user's environment. That way you can blast it all away > >> with a `make distclean`. > >> > >> Maybe the "make develop" target could even use the presence of a .venv > >> directory to know when it needs to make the environment or not ... > > [..] > >> For QEMU developers, installing with develop is going to be the smart > >> way to go. When your git tree is updated, your package will be updated > >> along with it. You can do it once and then probably forget about it. > > > > I don't think we can make this a manual step at all. Building QEMU > > requires running some Python scripts (e.g. the QAPI generator), so the > > setup needs to be done either in configure or in a Makefile target that > > is specified as a dependency of any rule that would run a Python script. > > Building QEMU once would then be enough. > > I am imagining that we might treat "building" and "testing" separately > -- as it is, builds require python3.5 and tests requires 3.6 which > definitely necessitates two distinct environments. I'm not sure what the exact definition of "end of life" of a distro is that we're using. I seem to remember that the reason for using Python 3.5 was Debian Stretch. Its official end of life is in about three weeks, but then there is still some LTS thing with reduced support done by a different group. If we read our policy literally and use the regular end of life, I guess we could just move QEMU to 3.6 for everything. > I will admit that I haven't constructed a full, coherent vision of > python management that encapsulates both building ad testing yet. For > example, should configure/make expect to be run inside of a venv, or > should they expect to create and then enter the venv? That's not clear > to me yet. I'm simultaneously trying to work out with Peter Maydell how > the sphinx dependency should work. Sphinx is presently our only python > dependency for our build environment.) It's kind of obvious that this can't require user interaction because we want ./configure; make to work. So I guess this means the venv needs to be set up automatically by configure/make? > Perhaps starting with the testing step is a good starting point and we > can use an implicit dependency on a `make develop` style step so it > happens automatically. > > (But perhaps keeping it as a standalone target that CAN be invoked > manually would be nice if you want to do some more intensive debugging > or development of new tests.) Yes. And you'll have many dependencies on it, so it would be a separate target anyway. > > Doing it automatically also means that we have to keep things local to > > the QEMU directory rather than installing them globally into the user > > directory. This is desirable anyway: Most of us deal with more than one > > QEMU source tree, so conflicts would be inevitable. > > I think it should be easy enough to put the VENV in the build directory > to prevent cross-contamination. Sure. I'm not overly familiar with all of this, but I guess my point was just that a venv is needed rather than a global installation into the user directory. If nobody ever suggested the latter, blame the misunderstanding on my non-existent experience with more complex Python setups. Kevin
On 6/19/20 12:44 PM, Kevin Wolf wrote: > Am 19.06.2020 um 17:04 hat John Snow geschrieben: >> On 6/18/20 5:23 AM, Kevin Wolf wrote: >>> Am 17.06.2020 um 22:27 hat John Snow geschrieben: >>>>> In the Avocado project, we have a `make develop` rule that does that >>>>> for the main setup.py file, and for all plugins we carry on the same >>>>> tree, which is similar in some regards to the "not at the project root >>>>> directory" situation here with "qemu/python/setup.py". >>>>> >>>> >>>> Ah, yeah. If we're going this far, I'd prefer using a VENV over >>>> modifying the user's environment. That way you can blast it all away >>>> with a `make distclean`. >>>> >>>> Maybe the "make develop" target could even use the presence of a .venv >>>> directory to know when it needs to make the environment or not ... >>> [..] >>>> For QEMU developers, installing with develop is going to be the smart >>>> way to go. When your git tree is updated, your package will be updated >>>> along with it. You can do it once and then probably forget about it. >>> >>> I don't think we can make this a manual step at all. Building QEMU >>> requires running some Python scripts (e.g. the QAPI generator), so the >>> setup needs to be done either in configure or in a Makefile target that >>> is specified as a dependency of any rule that would run a Python script. >>> Building QEMU once would then be enough. >> >> I am imagining that we might treat "building" and "testing" separately >> -- as it is, builds require python3.5 and tests requires 3.6 which >> definitely necessitates two distinct environments. > > I'm not sure what the exact definition of "end of life" of a distro is > that we're using. I seem to remember that the reason for using Python > 3.5 was Debian Stretch. Its official end of life is in about three > weeks, but then there is still some LTS thing with reduced support done > by a different group. > > If we read our policy literally and use the regular end of life, I guess > we could just move QEMU to 3.6 for everything. > I think we have kinda-sorta-agreed to exclude the third-party LTS support. I think we will be able to move to Python 3.6 shortly. That'd solve one problem. >> I will admit that I haven't constructed a full, coherent vision of >> python management that encapsulates both building ad testing yet. For >> example, should configure/make expect to be run inside of a venv, or >> should they expect to create and then enter the venv? That's not clear >> to me yet. I'm simultaneously trying to work out with Peter Maydell how >> the sphinx dependency should work. Sphinx is presently our only python >> dependency for our build environment.) > > It's kind of obvious that this can't require user interaction because we > want ./configure; make to work. So I guess this means the venv needs to > be set up automatically by configure/make? > >> Perhaps starting with the testing step is a good starting point and we >> can use an implicit dependency on a `make develop` style step so it >> happens automatically. >> >> (But perhaps keeping it as a standalone target that CAN be invoked >> manually would be nice if you want to do some more intensive debugging >> or development of new tests.) > > Yes. And you'll have many dependencies on it, so it would be a separate > target anyway. > >>> Doing it automatically also means that we have to keep things local to >>> the QEMU directory rather than installing them globally into the user >>> directory. This is desirable anyway: Most of us deal with more than one >>> QEMU source tree, so conflicts would be inevitable. >> >> I think it should be easy enough to put the VENV in the build directory >> to prevent cross-contamination. > > Sure. I'm not overly familiar with all of this, but I guess my point was > just that a venv is needed rather than a global installation into the > user directory. If nobody ever suggested the latter, blame the > misunderstanding on my non-existent experience with more complex Python > setups. > Python doesn't make it easy to understand, I think. I'll head along in this direction: We want testing to use a venv that exists in the build directory and we want to automate its creation and usage. I am still working out the role of Python/VENVs at configure time with Peter Maydell in another thread which may answer the other half of the equation for me. --js > Kevin >
On 6/18/20 11:23 AM, Kevin Wolf wrote: > Am 17.06.2020 um 22:27 hat John Snow geschrieben: >>> In the Avocado project, we have a `make develop` rule that does that >>> for the main setup.py file, and for all plugins we carry on the same >>> tree, which is similar in some regards to the "not at the project root >>> directory" situation here with "qemu/python/setup.py". >>> >> >> Ah, yeah. If we're going this far, I'd prefer using a VENV over >> modifying the user's environment. That way you can blast it all away >> with a `make distclean`. >> >> Maybe the "make develop" target could even use the presence of a .venv >> directory to know when it needs to make the environment or not ... > [..] >> For QEMU developers, installing with develop is going to be the smart >> way to go. When your git tree is updated, your package will be updated >> along with it. You can do it once and then probably forget about it. > > I don't think we can make this a manual step at all. Building QEMU > requires running some Python scripts (e.g. the QAPI generator), so the > setup needs to be done either in configure or in a Makefile target that > is specified as a dependency of any rule that would run a Python script. > Building QEMU once would then be enough. > > Doing it automatically also means that we have to keep things local to > the QEMU directory rather than installing them globally into the user > directory. This is desirable anyway: Most of us deal with more than one > QEMU source tree, so conflicts would be inevitable. Indeed. Each of the source tree I use has its own virtual environment. I personally stopped using the distribution packages, they don't make sense when you develop, the tree changes too quickly. Distributions use stable releases, so IMO it only makes sense to generate a package along with releases. Else use venv.
On 6/17/20 10:27 PM, John Snow wrote: > > > On 6/17/20 3:52 PM, Cleber Rosa wrote: >> On Tue, Jun 02, 2020 at 08:15:16PM -0400, John Snow wrote: [...] >> Are you proposing that we have, say, "python-qemu" version 10, being >> the 10th API version, without any regard to the QEMU version >> supported? Or version 10.5.3 would mean 10th API version, intended >> to support QEMU 5.3? >> > > I am proposing only that we use semver to track the API version of the > SDK itself. > > So that could be: > > A) 1.x, 2.x, 3.x (etc) with absolutely no connection to the intended > QEMU support version. It either works or it doesn't. It might not work > very spectacularly. Major semver bumps indicate a breaking change to the > library API. Major changes occurs between QEMU releases. If there is no QEMU release, it is pointless to release the python-qemu package, right? > > B) 1.5.0.0, 1.5.1.0, 1.5.2.0 (etc) where the major version still > describes the API, but the remainder of the version describes the > intended target QEMU. > > Or, we could do: > > C) 5.0.0, 5.1.0, 5.2.0, etc. where it tracks the QEMU version verbatim, > end of story. At least it KISS. > > I don't like (C) very much, because it violates some prevailing idioms > about python package versioning. A or B seem better, but do run us into > potential trouble with people having mismatched versions. Which is why I prefer (C). > > I'd take A or B. (B) is a little chatty but gives some good information > and allows you to pin versions effectively, so I think I'm leaning > towards that one right now. > > Well, whatever we do right now, I think I do really want to make sure we > are publishing under 0.x to really give the illustration that we are NOT > promising even the illusion of stability right now.
On 6/19/20 11:15 AM, Philippe Mathieu-Daudé wrote: > On 6/17/20 10:27 PM, John Snow wrote: >> >> >> On 6/17/20 3:52 PM, Cleber Rosa wrote: >>> On Tue, Jun 02, 2020 at 08:15:16PM -0400, John Snow wrote: > [...] >>> Are you proposing that we have, say, "python-qemu" version 10, being >>> the 10th API version, without any regard to the QEMU version >>> supported? Or version 10.5.3 would mean 10th API version, intended >>> to support QEMU 5.3? >>> >> >> I am proposing only that we use semver to track the API version of the >> SDK itself. >> >> So that could be: >> >> A) 1.x, 2.x, 3.x (etc) with absolutely no connection to the intended >> QEMU support version. It either works or it doesn't. It might not work >> very spectacularly. Major semver bumps indicate a breaking change to the >> library API. > > Major changes occurs between QEMU releases. If there is no QEMU release, > it is pointless to release the python-qemu package, right? > There might be fixes to the package that might be worth releasing out-of-band as point fixes. I don't intend to do this if I can help it, but I wanted to consider the possibility that unforeseen circumstances might force our hand. >> >> B) 1.5.0.0, 1.5.1.0, 1.5.2.0 (etc) where the major version still >> describes the API, but the remainder of the version describes the >> intended target QEMU. >> >> Or, we could do: >> >> C) 5.0.0, 5.1.0, 5.2.0, etc. where it tracks the QEMU version verbatim, >> end of story. > > At least it KISS. > Simple at a glance. I have some concerns about how Python packages are normally specified in e.g. requirements.txt where there's a habit of saying: package>=3.0.0, <4.0.0 There is a fairly common belief in the ecosystem that semver is being used. QEMU does not use semver. This leads us to a strange development paradigm in-tree where the Python package can have breaking changes from 5.x to 6.x, which are not otherwise special releases for QEMU itself. Combined with our deprecation policy, it means that we start adopting a policy like: - Features get deprecated for at least two releases - But can only be changed for a new "major" release. That mismatch against the QEMU versioning paradigm does not sound like KISS to me. >> >> I don't like (C) very much, because it violates some prevailing idioms >> about python package versioning. A or B seem better, but do run us into >> potential trouble with people having mismatched versions. > > Which is why I prefer (C). > Keep in mind that even though it looks more obvious, it still doesn't enforce the pairing. Problems with mismatched versions are just as likely to occur because of misconfigurations with requirements.txt. I guess my big concerns here are: 1. Using 1:1 QEMU versions (starting at 5.x) might imply API stability for the package, and I would like to avoid committing to that. We *can* declare the package as Alpha/Beta in PyPI, but in practice I am not sure that information is consulted as readily as version numbers are. 2. Python world (Citation Needed?) expects semver. We can ignore that if we choose; there aren't semver police. What are the consequences of doing that? 3. No matter what we do, the relationship between the Python package and the QEMU version is only superficial and isn't enforced anywhere. (And, I think, shouldn't be enforced.) >> >> I'd take A or B. (B) is a little chatty but gives some good information >> and allows you to pin versions effectively, so I think I'm leaning >> towards that one right now. >> >> Well, whatever we do right now, I think I do really want to make sure we >> are publishing under 0.x to really give the illustration that we are NOT >> promising even the illusion of stability right now. > It sounds like Avocado might be one of the biggest users of this, so I'd like to get some more feedback from Cleber, Wainer, et al. --js
© 2016 - 2024 Red Hat, Inc.