Derive package version from the git tag (setuptools_scm) - #64
Merged
Conversation
The version was hardcoded in pyproject.toml, so cutting a release tag did not change it: tagging v0.0.9 while pyproject still said 0.0.8 produced 0.0.8 wheels, which the PyPI upload then skipped as already-existing, so nothing shipped as 0.0.9. Make the version dynamic, sourced from the git tag via setuptools_scm, using the same scikit-build-core out-of-tree metadata provider as Genesis-Embodied-AI/nyx (the built-in provider is incompatible with setuptools_scm >=9). A release is now cut purely by tagging vX.Y.Z. - pyproject: dynamic = ["version"]; setuptools_scm build requirement; metadata.version.provider = "scm_version" (cmake/scm_version.py). - python-wheels.yml: fetch full tag history (fetch-depth: 0) so setuptools_scm can derive the version; cibuildwheel copies .git into the build container.
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.
Problem
The version was hardcoded in
pyproject.toml(version = "0.0.8"), so cutting a release tag didn't change it. Taggingv0.0.9while pyproject still said0.0.8builtgs_madrona-0.0.8wheels, which the PyPI upload then skipped as already-existing — so nothing shipped as 0.0.9 (0.0.9 is currently empty on PyPI).Fix
Derive the version from the git tag via
setuptools_scm, using the same scikit-build-core out-of-tree metadata provider asnyx(the built-inscikit_build_core.metadata.setuptools_scmprovider is incompatible with setuptools_scm >= 9). A release is then cut purely by taggingvX.Y.Z— there is no version string to bump by hand.dynamic = ["version"];setuptools_scm>=8build requirement;metadata.version.provider = "scm_version"→cmake/scm_version.py;experimental = true.fetch-depth: 0for tag history, and forward the runner-resolved version into cibuildwheel's manylinux containers viaSETUPTOOLS_SCM_PRETEND_VERSION(setuptools_scm can't read git inside the build container, and would otherwise fall back to0.0.0+unknown).Validation
Building the sdist through scikit-build-core resolves the version from the tag end-to-end:
The
.dev0/date suffix is only the dirty worktree during testing; a clean tagged commit yields the exact tag (e.g.0.0.9).Once this lands, the
v0.0.9tag/release will be recreated on top of it so the release builds and publishes0.0.9correctly.