| 6ccb48ff | 15-Jul-2025 |
Daniel P. Berrangé <berrange@redhat.com> |
python: ensure QEMUQtestProtocol closes its socket
While QEMUQtestMachine closes the socket that was passed to QEMUQtestProtocol, the python resource leak manager still believes that the copy QEMUQt
python: ensure QEMUQtestProtocol closes its socket
While QEMUQtestMachine closes the socket that was passed to QEMUQtestProtocol, the python resource leak manager still believes that the copy QEMUQtestProtocol holds is open. We must explicitly call close to avoid this leak warnnig.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| f414048e | 26-Aug-2025 |
John Snow <jsnow@redhat.com> |
python: synchronize qemu.qmp documentation
This patch collects comments and documentation changes from many commits in the python-qemu-qmp repository; bringing the qemu.git copy in bit-identical ali
python: synchronize qemu.qmp documentation
This patch collects comments and documentation changes from many commits in the python-qemu-qmp repository; bringing the qemu.git copy in bit-identical alignment with the standalone library *except* for several copyright messages that reference the "LICENSE" file which is, for QEMU, named "COPYING" instead and are therefore left unchanged.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| 85f223e5 | 03-Sep-2025 |
John Snow <jsnow@redhat.com> |
python: backport 'avoid creating additional event loops per thread'
This commit is two backports squashed into one to avoid regressions.
python: *really* remove get_event_loop
A prior commit, aa1f
python: backport 'avoid creating additional event loops per thread'
This commit is two backports squashed into one to avoid regressions.
python: *really* remove get_event_loop
A prior commit, aa1ff990, switched away from using get_event_loop *by default*, but this is not good enough to avoid deprecation warnings as `asyncio.get_event_loop_policy().get_event_loop()` is *also* deprecated. Replace this mechanism with explicit calls to asyncio.get_new_loop() and revise the cleanup mechanisms in __del__ to match.
python: avoid creating additional event loops per thread
"Too hasty by far!", commit 21ce2ee4 attempted to avoid deprecated behavior altogether by calling new_event_loop() directly if there was no loop currently running, but this has the unfortunate side effect of potentially creating multiple event loops per thread if tests instantiate multiple QMP connections in a single thread. This behavior is apparently not well-defined and causes problems in some, but not all, combinations of Python interpreter version and platform environment.
Partially revert to Daniel Berrange's original patch, which calls get_event_loop and simply suppresses the deprecation warning in Python<=3.13. This time, however, additionally register new loops created with new_event_loop() so that future calls to get_event_loop() will return the loop already created.
Reported-by: Richard W.M. Jones <rjones@redhat.com> Reported-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@21ce2ee4f2df87efe84a27b9c5112487f4670622 cherry picked from commit python-qemu-qmp@c08fb82b38212956ccffc03fc6d015c3979f42fe Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| 5d99044d | 13-Aug-2024 |
John Snow <jsnow@redhat.com> |
python: backport 'Remove deprecated get_event_loop calls'
This method was deprecated in 3.12 because it ordinarily should not be used from coroutines; if there is not a currently running event loop,
python: backport 'Remove deprecated get_event_loop calls'
This method was deprecated in 3.12 because it ordinarily should not be used from coroutines; if there is not a currently running event loop, this automatically creates a new event loop - which is usually not what you want from code that would ever run in the bottom half.
In our case, we do want this behavior in two places:
(1) The synchronous shim, for convenience: this allows fully sync programs to use QEMUMonitorProtocol() without needing to set up an event loop beforehand. This is intentional to fully box in the async complexities into the legacy sync shim.
(2) The qmp_tui shell; instead of relying on asyncio.run to create and run an asyncio program, we need to be able to pass the current asyncio loop to urwid setup functions. For convenience, again, we create one if one is not present to simplify the creation of the TUI appliance.
The remaining user of get_event_loop() was in fact one of the erroneous users that should not have been using this function: if there's no running event loop inside of a coroutine, you're in big trouble :)
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@aa1ff9907603a3033296027e1bd021133df86ef1 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| fd0ed46d | 22-Jul-2022 |
John Snow <jsnow@redhat.com> |
python: backport 'qmp-tui: Do not crash if optional dependencies are not met'
Based on the discussion at https://github.com/pypa/pip/issues/9726 - even though the setuptools documentation implies th
python: backport 'qmp-tui: Do not crash if optional dependencies are not met'
Based on the discussion at https://github.com/pypa/pip/issues/9726 - even though the setuptools documentation implies that it is possible to guard script execution with optional dependency groups, this is not true in practice with the scripts generated by pip.
Just do the simple thing and guard the import statements.
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@df520dcacf9a75dd4c82ab1129768de4128b554c Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| fcaeeb76 | 22-Jul-2022 |
John Snow <jsnow@redhat.com> |
python: backport 'qmp-shell-wrap: handle missing binary gracefully'
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@9c889dcbd58817b0c917a9d2dd16161f48ac8203 Sig
python: backport 'qmp-shell-wrap: handle missing binary gracefully'
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@9c889dcbd58817b0c917a9d2dd16161f48ac8203 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| a50b8572 | 02-May-2022 |
John Snow <jsnow@redhat.com> |
python: backport 'make require() preserve async-ness'
This is not strictly needed functionality-wise, but doing this allows sphinx to see which decorated methods are async. Without this, sphinx miss
python: backport 'make require() preserve async-ness'
This is not strictly needed functionality-wise, but doing this allows sphinx to see which decorated methods are async. Without this, sphinx misses the "async" classifier on generated docs, which ... for an async library, isn't great.
It does make an already gnarly function even gnarlier, though.
So, what's going on here?
A synchronous function (like require() before this patch) can return a coroutine that can be awaited on, for example:
def some_func(): return asyncio.task(asyncio.sleep(5))
async def some_async_func(): await some_func()
However, this function is not considered to be an "async" function in the eyes of the abstract syntax tree. Specifically, some_func.__code__.co_flags will not be set with CO_COROUTINE.
The interpreter uses this flag to know if it's legal to use "await" from within the body of the function. Since this function is just wrapping another function, it doesn't matter much for the decorator, but sphinx uses the stdlib inspect.iscoroutinefunction() to determine when to add the "async" prefix in generated output. This function uses the presence of CO_COROUTINE.
So, in order to preserve the "async" flag for docs, the require() decorator needs to differentiate based on whether it is decorating a sync or async function and use a different wrapping mechanism accordingly.
Phew.
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@40aa9699d619849f528032aa456dd061a4afa957 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| 653f5014 | 14-Apr-2025 |
Adam Dorsey <adam.dorsey@twosixtech.com> |
python: backport 'feat: allow setting read buffer limit'
Expose the limit parameter of the underlying StreamReader and StreamWriter instances.
This is helpful for the use case of transferring files
python: backport 'feat: allow setting read buffer limit'
Expose the limit parameter of the underlying StreamReader and StreamWriter instances.
This is helpful for the use case of transferring files in and out of a VM via the QEMU guest agent's guest-file-open, guest-file-read, guest-file-write, and guest-file-close methods, as it allows pushing the buffer size up to the guest agent's limit of 48MB per transfer.
Signed-off-by: Adam Dorsey <adam@dorseys.email> cherry picked from commit python-qemu-qmp@9ba6a698344eb3b570fa4864e906c54042824cd6 cherry picked from commit python-qemu-qmp@e4d0d3f835d82283ee0e48438d1b154e18303491 [Squashed in linter fixups. --js] Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| 8fd9cceb | 22-Jul-2022 |
John Snow <jsnow@redhat.com> |
python: backport 'qmp-shell: add common_parser()'
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@20a88c2471f37d10520b2409046d59e1d0f1e905 Signed-off-by: John S
python: backport 'qmp-shell: add common_parser()'
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@20a88c2471f37d10520b2409046d59e1d0f1e905 Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| 0408b8d7 | 06-Jun-2023 |
John Snow <jsnow@redhat.com> |
python: backport 'Use @asynciocontextmanager'
This removes a non-idiomatic use of a "coroutine callback" in favor of something a bit more standardized.
Signed-off-by: John Snow <jsnow@redhat.com> c
python: backport 'Use @asynciocontextmanager'
This removes a non-idiomatic use of a "coroutine callback" in favor of something a bit more standardized.
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@commit 97f7ffa3be17a50544b52767d14b6fd478c07b9e Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| f9d2e0a3 | 06-Jun-2023 |
John Snow <jsnow@redhat.com> |
python: backport 'drop Python3.6 workarounds'
Now that the minimum version is 3.7, drop some of the 3.6-specific hacks we've been carrying. A single remaining compatibility hack concerning 3.6's lac
python: backport 'drop Python3.6 workarounds'
Now that the minimum version is 3.7, drop some of the 3.6-specific hacks we've been carrying. A single remaining compatibility hack concerning 3.6's lack of @asynccontextmanager is addressed in the following commit.
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@3e8e34e594cfc6b707e6f67959166acde4b421b8 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| 094ded52 | 22-Jul-2022 |
John Snow <jsnow@redhat.com> |
python: backport 'protocol: adjust logging name when changing client name'
The client name is mutable, so the logging name should also change to reflect it when it changes.
Signed-off-by: John Snow
python: backport 'protocol: adjust logging name when changing client name'
The client name is mutable, so the logging name should also change to reflect it when it changes.
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@e10b73c633ce138ba30bc8beccd2ab31989eaf3d Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| 1e343714 | 03-May-2022 |
John Snow <jsnow@redhat.com> |
python: backport 'kick event queue on legacy event_pull()'
This corrects an oversight in qmp-shell operation where new events will not accumulate in the event queue when pressing "enter" with an emp
python: backport 'kick event queue on legacy event_pull()'
This corrects an oversight in qmp-shell operation where new events will not accumulate in the event queue when pressing "enter" with an empty command buffer, so no new events show up.
Reported-by: Jag Raman <jag.raman@oracle.com> Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@0443582d16cf9efd52b2c41a7b5be7af42c856cd Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| cb0e4380 | 22-Jul-2022 |
John Snow <jsnow@redhat.com> |
python: backport 'EventListener: add __repr__ method'
When the object is not stateful, this repr method prints what you'd expect. In cases where there are pending events, the output is augmented to
python: backport 'EventListener: add __repr__ method'
When the object is not stateful, this repr method prints what you'd expect. In cases where there are pending events, the output is augmented to illustrate that.
The object itself has no idea if it's "active" or not, so it cannot convey that information.
Signed-off-by: John Snow <jsnow@redhat.com> cherry picked from commit python-qemu-qmp@8a6f2e136dae395fec8aa5fd77487cfe12d9e05e Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
| 64e4375b | 15-Jul-2025 |
John Snow <jsnow@redhat.com> |
python: fix editable installs for modern pip/setuptools
The way editable installs work has changed at some point since Fedora 40 was released. Generally, we should be opting to use pyproject.toml in
python: fix editable installs for modern pip/setuptools
The way editable installs work has changed at some point since Fedora 40 was released. Generally, we should be opting to use pyproject.toml installs (PEP517/518) - but those are not fully supported until v61 of setuptools, and CentOS Stream 9 ships v53.
Until that time, we can make use of a transitional feature in pip/setuptools to use "legacy" editable installs, which is enough to fix "make check-dev" on modern local workstations for now.
By using the environment variable approach to configure pip, we avoid any problems for older versions of pip that don't recognize this option, so it's harmless. The config-settings option first appeared in v23 of pip. editable_mode was first supported by setuptools in v64.
(I'm not currently precisely aware of when the default behavior of '-e' switched away from 'compat', but it appears to be a joint effect between setuptools and pip versions.)
Version information for supported build platforms:
distro python3 pip setuptools sphinx -------------------------------------------------------- centos_stream_9 3.9.23 21.3.1 53.0.0 3.4.3 ubuntu_22_04 3.10.12 22.0.2 59.6.0 4.3.2
** pyproject.toml installs supported as of here **
freebsd 3.11.13 23.3.2 63.1.0 5.3.0 debian_12 3.11.2 23.0.1 66.1.1 5.3.0 ubuntu_24_04 3.12.3 24.0 68.1.2 7.2.6 centos_stream_10 3.12.11 23.3.2 69.0.3 7.2.6 fedora_41 3.13.5 24.2 69.2.0 7.3.7 alpine_3_19 3.11.13 23.3.1 70.3.0 6.2.1 alpine_3_20 3.12.11 24.0 70.3.0 7.2.6 alpine_3_21 3.12.11 24.3.1 70.3.0 8.1.3 ubuntu_24_10 3.12.7 24.2 74.1.2 7.4.7 fedora_42 3.13.5 24.3.1 74.1.3 8.1.3 ubuntu_25_04 3.13.3 25.0 75.8.0 8.1.3 macports 3.13.5 25.1.1 78.1.1 8.2.3 openbsd 3.12.11 25.1.1 79.0.1 8.2.3 alpine_3_22 3.12.11 25.1.1 80.9.0 8.2.3 homebrew 3.13.5 --- 80.9.0 8.2.3 pkgsrc_current 3.12.11 25.1.1 80.9.0 8.2.3
Signed-off-by: John Snow <jsnow@redhat.com> Message-ID: <20250715222548.198888-1-jsnow@redhat.com> Tested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
| 781e7305 | 04-Jun-2025 |
Markus Armbruster <armbru@redhat.com> |
python: Drop redundant warn_unused_configs = True
strict = True implies warn_unused_configs = True.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
python: Drop redundant warn_unused_configs = True
strict = True implies warn_unused_configs = True.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: 20250604200354.459501-6-jsnow@redhat.com
show more ...
|