On 10/28/20 3:51 PM, Cleber Rosa wrote:
On Tue, Oct 20, 2020 at 03:35:43PM -0400, John Snow wrote:
Python infrastructure as it exists today is not capable reliably of
single-sourcing a package version from a parent directory. The authors
of pip are working to correct this, but as of today this is not possible
to my knowledge.
The problem is that when using pip to build and install a python
package, it copies files over to a temporary directory and performs its
build there. This loses access to any information in the parent
directory, including git itself.
Further, Python versions have a standard (PEP 440) that may or may not
follow QEMU's versioning. In general, it does; but naturally QEMU does
not follow PEP 440. To avoid any automatically-generated conflict, a
manual version file is preferred.
I am proposing:
- Python tooling follows the QEMU version, indirectly, but with a major
version of 0 to indicate that the API is not expected to be
stable. This would mean version 0.5.2.0, 0.5.1.1, 0.5.3.0, etc.
- In the event that a Python package needs to be updated independently
of the QEMU version, a pre-release alpha version should be preferred,
but *only* after inclusion to the qemu development or stable branches.
e.g. 0.5.2.0a1, 0.5.2.0a2, and so on should be preferred prior to
5.2.0's release.
- The Python core tooling makes absolutely no version compatibility
checks or constraints. It *may* work with releases of QEMU from the
past or future, but it is not required to.
i.e., "qemu.machine" will always remain in lock-step with QEMU.
- We reserve the right to split the qemu package into independently
versioned subpackages at a later date. This might allow for us to
begin versioning QMP independently from QEMU at a later date, if
we so choose.
Implement this versioning scheme by adding a VERSION file and setting it
to 0.5.2.0a1.
Signed-off-by: John Snow <js...@redhat.com>
I'd rather have the version to be sync'd with QEMU, but, I understand
this is a more conservative approach that can maybe evolve into that.
Reviewed-by: Cleber Rosa <cr...@redhat.com>
It's definitely me taking the cowardly way out. I did use the exact QEMU
version in the last spin, because that seemed like the dumbest thing :)
I think qemu.machine would eventually evolve to track the QEMU version
directly, whereas qemu.qmp would evolve to keep its own independent
versioning system.
This is just, I guess, one more semantic nudge towards the idea that
this is really an independent little component. I just want to give it
some more time in the oven before I declare it truly and genuinely
supported as its own project. Once it's on PyPI, I am beholden to more
than the other QEMU contributors. Satisfying both crowds simultaneously
seems like it will be tough.
--js
