Scmversion #3606
Scmversion #3606
Conversation
behrmann
force-pushed
the
scmversion
branch
2 times, most recently
from
9a58e59 to
8f491df
Compare
|
Also, what happens when people have installed (an older version) of mkosi via pip (or their distro) but call a local mkosi clone via the |
behrmann
force-pushed
the
scmversion
branch
4 times, most recently
from
28d7843 to
7fbc3be
Compare
Good catch, added a check for that. |
I think it's nicer to have it in the module, since it gives the power of both a proper language as well as making it unnecessery to implement this multiple times. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
behrmann
force-pushed
the
scmversion
branch
2 times, most recently
from
6729251 to
6efdd7a
Compare
This should make it easier to install all necessary tools for development.
|
I've tested this with for mkosi, mkosi-addon, mkosi-initrd and mkosi-sandbox
All of them with a distribution mkosi installed and not installed. All output a version like |
behrmann
force-pushed
the
scmversion
branch
4 times, most recently
from
e759d2b to
a98652e
Compare
This commit changes the versioning scheme of non-release versions of mkosi to
align with the standard Python version scheme [1]. Unfortunately this scheme is
not fully compatible with the UAPI group version format specification.
Concretely, this changes
26~devel
to
25.3.post1.dev244+g0eac3718
The used format ensures that for prereleases the following inequalities still
hold
25.3 < 25.3.post1.dev244+g0eac3718 < 25.4 < 26
Usage of this new format has the following benefits:
1. It is compatible with PyPI and allows publishing mkosi there in the future
2. Since it contains the number of commits since the last tag as well as part
of the commit hash in the "local part" of the version, it becomes easier for
bug reporters to show the version they are on no matter how mkosi has been
installed.
3. The version no longer needs to be managed in multiple places.
The current implementation moves the version from mkosi/sandbox.py to a new
file _version.py that obtains the version either via importlib metadata (in
case mkosi has been installed) or by calling setuptools-scm directly, to
support the bin/ shims. Since the version is no longer available in
mkosi/sandbox.py, it passed as an environment variable for scripts.
[1] https://packaging.python.org/en/latest/specifications/version-specifiers/
| def version_from_git() -> Optional[str]: | ||
| try: | ||
| p = subprocess.run( | ||
| ["git", "describe"], | ||
| cwd=Path(__file__).parent.parent, | ||
| check=True, | ||
| text=True, | ||
| capture_output=True, | ||
| ) | ||
| # output has form like v25.3-244-g8f491df9 when not on a tag, else just the tag | ||
| tag, *rest = p.stdout.strip().split("-") | ||
| tag = tag.lstrip("v") | ||
| if rest: | ||
| numcommits, commit = rest | ||
| return f"{tag}.post1.dev{numcommits}+{commit}.d{datetime.datetime.now():%Y%m%d}" | ||
|
|
||
| # we are exactly on a tag | ||
| return tag | ||
| except (subprocess.CalledProcessError, NotADirectoryError, FileNotFoundError): | ||
| return None |
There was a problem hiding this comment.
So this completely goes against the convention we adopted in systemd to have the devel version be of the next version we've developing, which is fundamentally incompatible with git describe since that will always return the latest tag which is the previous version.
There was a problem hiding this comment.
To document the current state for others:
We're a bit between the rock of UAPI version format spec and the hard place of Python's public version identifiers.
Both are compatible as far as the set of allowed characters for Python's scheme is (mostly) subset (disregarding the local part divided by + and the epoch divided by !, but systemd-analyze compare-version will happily treat them as separators, so that's fine), unfortunately the semantics are different. Whereas the UAPI spec follows RPM an .deb and has sigils that raise or lower a version, allowing not having to keep state and being able to compare version strings character by character, Python has multicharater substrings like .dev or .rc that take their place.
Using a version scheme anchored on the last release and counting commits since, allows to fit into both schemes, as described above, since this will hold
25 < 25.3 < 25.3.post1.dev244+g0eac3718 < 25.4 < 26
Unfortunately, there is no way to construct a version starting with the next release number, that compares smaller than that release under both the UAPI version spec and Python's, e.g. 26rc244 would compare smaller than 26 in under Python's scheme, but compares larger under the UAPI scheme, simply because it is shorter.
This commit changes the versioning scheme of non-release versions of mkosi to
align with the standard Python version scheme [1]. Unfortunately this scheme is
not fully compatible with the UAPI group version format specification.
Concretely, this changes
to
The used format ensures that for prereleases the following inequalities still
hold
Usage of this new format has the following benefits:
It is compatible with PyPI and allows publishing mkosi there in the future
Since it contains the number of commits since the last tag as well as part
of the commit hash in the "local part" of the version, it becomes easier for
bug reporters to show the version they are on no matter how mkosi has been
installed.
The version no longer needs to be managed manually.
The current implementation moves the version from mkosi/sandbox.py to a new
file _version.py that obtains the version either via importlib metadata (in
case mkosi has been installed) or by calling setuptools-scm directly, to
support the bin/ shims. Since the version is no longer available in
mkosi/sandbox.py, it passed as an environment variable for scripts.
[1] https://packaging.python.org/en/latest/specifications/version-specifiers/