Derive package version from git tags (hatch-vcs) - #53
Merged
Conversation
Replace the hardcoded project.version with hatch-vcs dynamic versioning so the version comes from the git tag at build time, instead of a number that has to be hand-edited before each release (the mismatch that broke the v0.5.2 release: pyproject still said 0.5.1, so the build produced an already-published artifact and twine 409'd). Switch the build backend setuptools -> hatchling and add fetch-depth: 0 to the two release jobs that build, so the tag is present for hatch-vcs to read.
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.
Why
The
v0.5.2release workflow failed becausepyproject.tomlstill hardcodedversion = "0.5.1".python -m buildproducedleaflux-0.5.1, which already exists on PyPI, sotwine upload409'd. The version number has to be hand-edited before every release, and it's easy to forget.What
dynamic = ["version"]). Same approachfastfuels-corealready uses.fetch-depth: 0to the two release jobs that build (upload-to-test-pypi,upload-to-pypi) so the tag is present for hatch-vcs to read. The two test jobs install from PyPI and don't build, so they're untouched.Verified locally
vX.Y.Ztag buildsleaflux-X.Y.Zexactly..devN+g<sha>version (expected).leaflux/package (6 modules) + dist-info — nodocs/,test/, ordata/.The existing
v0.5.2tag points at the old (setuptools) commit, so it won't pick this up. After merge, either re-tagv0.5.2(delete + recreate on the newmain) or cut a freshv0.5.3release.0.5.2was never published, so either is clean.