build: derive the project version from the newest git tag - #876
Merged
Merged
Conversation
[project].version was a written number that had to be kept in step with the tag by hand. hatch-vcs derives it from `git describe` instead, so the two cannot drift: the number lives in one place. uv omits the version field for a dynamic root package, so uv.lock loses its own version line and does not churn per commit. [tool.bumpversion] stays and falls back to the newest tag, which is the same source the build reads. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Derive
[project].versionfrom the newest git tag instead of writing it intopyproject.toml.dynamic = ["version"]in[project],hatch-vcsadded to the build requires, and[tool.hatch.version] source = "vcs".uv.lockloses its root-packageversionline: uv omits the field entirely for a dynamic root, so there is no per-commit churn.[tool.bumpversion]stays. With no written number it reads the newest tag viagit describe— the same source hatch-vcs builds from, so the bump it offers and the version it produces cannot disagree. Its comment is updated to say so.Why this is safe here:
rhiza_release.ymlis already built for VCS-derived versions: every job checks out withfetch-depth: 0, and afteruv buildit verifies the built distribution's filename against the tag — the one place a derived version can be caught being wrong.__version__is resolved throughimportlib.metadataat import time, so runtime versioning is unaffected.pytest-rhiza'stest_pyproject(0.6.0, the rhiza-task@1.7.0 default) tolerates a dynamic version: 22 pass, 6 skip with a stated reason.Verified locally:
uv lock,uv build(produces the expected.devN+g<sha>off-tag version), the rhiza pyproject checks, and the version/metadata tests.No gates beyond those were run — CI is the check.