| e8e4298f | 05-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)", 2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for tests
tests: Use separate virtual environment for avocado
This reverts commits eea2d141179 ("Makefile: remove $(TESTS_PYTHON)", 2023-05-26) and 9c6692db550 ("tests: Use configure-provided pyvenv for tests", 2023-05-18).
Right now, there is a conflict between wanting a ">=" constraint when using a distro-provided package and wanting a "==" constraint when installing Avocado from PyPI; this would provide the best of both worlds in terms of resiliency for both distros that have required packages and distros that don't.
The conflict is visible also for meson, where we would like to install the latest 0.63.x version but also accept a distro 1.1.x version. But it is worse for avocado, for two reasons:
1) we cannot use an "==" constraint to install avocado if the venv includes a system avocado. The distro will package plugins that have "==" constraints on the version that is included in the distro, and, using "pip install avocado==88.1" on a venv that includes system packages will result in this error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible. avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible. make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
2) we cannot use ">=" either if the venv does _not_ include a system avocado, because that would result in the installation of v101.0 which is the one we've just reverted.
So the idea is to encode the dependencies as an (acceptable, locked) tuple, like this hypothetical TOML that would be committed inside python/ and used by mkvenv.py:
[meson] meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }
[docs] # 6.0 drops support for Python 3.7 sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" } sphinx_rtd_theme = { minimum = "0.5" }
[avocado] avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }
Once this is implemented, it would also be possible to install avocado in pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora and CentOS Stream (the only distros where it's available). But until this is implemented, keep avocado in a separate venv. There is still the benefit of using a single python for meson custom_targets and for sphinx.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| fe3ab4eb | 18-Oct-2022 |
Paolo Bonzini <pbonzini@redhat.com> |
docs/devel: update build system docs
configure is only doing compiler and host setup now, so adjust the relevant documentation. It is also possible to build emulators with ninja directly if one is
docs/devel: update build system docs
configure is only doing compiler and host setup now, so adjust the relevant documentation. It is also possible to build emulators with ninja directly if one is so inclined, so mention that as well.
The Python virtual environment set up is a new major task of configure as well. Mention it in the list of produced files, while leaving it for a future patch to document how it works and how ``mkvenv ensure`` is used.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 9d167491 | 28-Apr-2023 |
Markus Armbruster <armbru@redhat.com> |
docs/devel/qapi-code-gen: Update doc comment conventions
The commit before previous relaxed the indentation rules to let us improve the doc comment conventions. This commit changes the written conv
docs/devel/qapi-code-gen: Update doc comment conventions
The commit before previous relaxed the indentation rules to let us improve the doc comment conventions. This commit changes the written conventions. The next commits will update QAPI schemas to conform to them.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230428105429.1687850-16-armbru@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com>
show more ...
|
| 08349786 | 28-Apr-2023 |
Markus Armbruster <armbru@redhat.com> |
qapi: Relax doc string @name: description indentation rules
The QAPI schema doc comment language provides special syntax for command and event arguments, struct and union members, alternate branches
qapi: Relax doc string @name: description indentation rules
The QAPI schema doc comment language provides special syntax for command and event arguments, struct and union members, alternate branches, enumeration values, and features: descriptions starting with "@name:".
By convention, we format them like this:
# @name: Lorem ipsum dolor sit amet, consectetur adipiscing elit, # sed do eiusmod tempor incididunt ut labore et dolore # magna aliqua.
Okay for names as short as "name", but we have much longer ones. Their description gets squeezed against the right margin, like this:
# @dirty-sync-missed-zero-copy: Number of times dirty RAM synchronization could # not avoid copying dirty pages. This is between # 0 and @dirty-sync-count * @multifd-channels. # (since 7.1)
The description text is effectively just 50 characters wide. Easy enough to read, but can be cumbersome to write.
The awkward squeeze against the right margin makes people go beyond it, which produces two undesirables: arguments about style, and descriptions that are unnecessarily hard to read, like this one:
# @postcopy-vcpu-blocktime: list of the postcopy blocktime per vCPU. This is # only present when the postcopy-blocktime migration capability # is enabled. (Since 3.0)
We could instead format it like
# @postcopy-vcpu-blocktime: # list of the postcopy blocktime per vCPU. This is only present # when the postcopy-blocktime migration capability is # enabled. (Since 3.0)
or, since the commit before previous, like
# @postcopy-vcpu-blocktime: # list of the postcopy blocktime per vCPU. This is only present # when the postcopy-blocktime migration capability is # enabled. (Since 3.0)
However, I'd rather have
# @postcopy-vcpu-blocktime: list of the postcopy blocktime per vCPU. # This is only present when the postcopy-blocktime migration # capability is enabled. (Since 3.0)
because this is how rST field and option lists work.
To get this, we need to let the first non-blank line after the "@name:" line determine expected indentation.
This fills up the indentation pitfall mentioned in docs/devel/qapi-code-gen.rst. A related pitfall still exists. Update the text to show it.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230428105429.1687850-14-armbru@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> [Work around lack of walrus operator in Python 3.7 and older]
show more ...
|
| f57e1d05 | 28-Apr-2023 |
Markus Armbruster <armbru@redhat.com> |
sphinx/qapidoc: Do not emit TODO sections into user manuals
QAPI doc comments are for QMP users: they go into the "QEMU QMP Reference Manual" and the "QEMU Storage Daemon QMP Reference Manual".
The
sphinx/qapidoc: Do not emit TODO sections into user manuals
QAPI doc comments are for QMP users: they go into the "QEMU QMP Reference Manual" and the "QEMU Storage Daemon QMP Reference Manual".
The doc comment TODO sections are for somebody else, namely for the people who can do: developers. Do not emit them into the user manuals.
This elides the following TODOs:
* SchemaInfoCommand
# TODO: @success-response (currently irrelevant, because it's QGA, not QMP)
This is a note to developers adding introspection to the guest agent. It makes no sense to users.
* @query-hotpluggable-cpus
# TODO: Better documentation; currently there is none.
This is a reminder for developers. It doesn't help users.
* @device_add
# TODO: This command effectively bypasses QAPI completely due to its # "additional arguments" business. It shouldn't have been added to # the schema in this form. It should be qapified properly, or # replaced by a properly qapified command.
Likewise.
Eliding them is an improvement.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230428105429.1687850-7-armbru@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com>
show more ...
|
| a2836b32 | 28-Apr-2023 |
Markus Armbruster <armbru@redhat.com> |
docs/devel/qapi-code-gen: Turn FIXME admonitions into comments
We have two FIXME notes. These FIXMEs are for QAPI developers. They are not useful for QAPI schema developers. They are marked up as
docs/devel/qapi-code-gen: Turn FIXME admonitions into comments
We have two FIXME notes. These FIXMEs are for QAPI developers. They are not useful for QAPI schema developers. They are marked up as admonitions, which makes them look important in generated HTML.
Turn them into comments. QAPI developers will still see them (they read and write the .rst). QAPI schema developers may still see them (if they read the .rst instead of the generated .html), but "this is just for QAPI developers" should be more obvious.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230428105429.1687850-3-armbru@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com>
show more ...
|