Derive package version from git tags via hatch-vcs#67
Merged
Conversation
Replace the static version with git-tag-derived versioning (hatch-vcs / setuptools-scm) so every commit builds with a unique, increasing version such as 1.2.1.devN+g<sha>. Plain pip and uv installs from git then pick up new commits even into an existing environment, without manual bumps. - Anchored by tag v1.2.0 on main (matches the previous static version) - fetch-depth: 0 in workflows that install the package, so CI derives the real version instead of a 0.1.devN shallow-clone fallback - .git_archival.txt + .gitattributes so GitHub source archives (Download ZIP) of any commit reachable from a tag still build
fetch-depth: 0 on this ~360 MB repo downloads every historical blob just to give hatch-vcs the tag topology; filter: blob:none keeps the version derivation correct while fetching only checkout-reachable blobs.
Reads the installed distribution metadata (importlib.metadata), so it reports the same git-tag-derived version hatch-vcs builds into the package.
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 static
version = "1.2.0"never changed whilemainmoved, so pip users updating an existing environment silently kept stale code: pip treats anhflodata @ git+...@mainrequirement as satisfied when the installed version equals the freshly resolved one — verified empirically that not evenpip install -Upicks up new commits; only--force-reinstalldid. hatch+uv setups were unaffected, but plain pip needs the version to actually increase.What
1.2.1.devN+g<sha>— unique and strictly increasing per commit, so all installers pick up changes without manual bumps.v1.2.0pushed on the previous main tip (matches the old static version, no downgrade anywhere).fetch-depth: 0in the two workflows that install the package — a shallow tagless checkout otherwise derives a0.1.devNfallback version (cosmetic; tests never asserted on it)..git_archival.txt+.gitattributes(export-subst) so GitHub 'Download ZIP' archives of commits reachable from a tag still build correctly.Verified
Installed from this branch with both pip 25 and uv 0.10: version resolves to
1.2.1.dev1+g096c3e784. With increasing versions, a plainpip installover an existing environment now upgrades whenmainmoves (tested with a real stale-commit scenario).Release process from now on
Cut a release by tagging:
git tag -a v1.3.0 -m ... && git push origin v1.3.0. No version-bump commits needed; the version line in pyproject.toml is gone.