fix(build): leech_core's version tracks leech's, and a mismatch is visible - #204
Merged
Merged
Conversation
…sible leech_core sat at 0.3.0 from v0.3.1 to v0.6.4 -- ten releases, spanning #176, #185, #187, #188, #192, #195, #200 and #202 -- while the Rust changed underneath it. The string is not decoration: uv keys its archive cache on it, so `uv sync` could restore a compiled extension built from any earlier revision that shared the version, over a current build. Caught it doing exactly that: 43 tests failing with pre-#188 behaviour (chunk_signal_kmer_inputs no longer snapping map[0] = 0) against an up-to-date working tree. rust/Cargo.toml is now the single source and tracks leech's version; rust/pyproject.toml takes it through `dynamic = ["version"]` rather than carrying a third copy to keep in sync. leech_core also exports __version__ now, via env!(CARGO_PKG_VERSION), and check_rust() compares it against leech.__version__. The two are separate distributions built from one repository, so a cross-revision pairing does not raise -- it produces different numbers, which is how #176 stayed hidden. check_rust() printed a bare "leech_core" with no version; it now names it and says which half to rebuild, including the case where the stale half is leech's own editable metadata. The release skill bumps both and re-verifies check_rust() afterwards, so this cannot drift again by omission.
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.
Answers "is the leech_core version moving with the main version?" — it was not, by ten releases.
leechleech_core0.3.0→0.3.0Across that window the Rust changed repeatedly: #176/#178 (POD5 cache + concurrency), #185, #187, #188, #192, #194, #195, #200, #202. Same version string every time.
Why that string matters
It is not decoration — it is a cache key.
uvkeys its archive cache on it, so a version that never moves letsuv syncrestore a compiled extension built from any earlier revision that shared it, on top of a current build.I hit this while working on #203: after a routine
uv sync --extra rust, 43 tests failed with pre-#188 behaviour —chunk_signal_kmer_inputsno longer snappingmap[0] = 0, givings2s[0] == -232— against an up-to-date working tree.~/.cache/uv/archive-v0/was holding both aleech_core-0.1.0and a0.3.0archive. The only reason I did not blame my own change is that the failing test runs with refinement off, so a Python-only refinement edit could not have caused it.What changes
1.
rust/Cargo.tomltracksleech's version and is the single source.rust/pyproject.tomlnow declaresdynamic = ["version"]instead of carrying a second copy — there were nearly three, sinceenv!("CARGO_PKG_VERSION")reads Cargo.toml while maturin's wheel metadata reads pyproject.2.
leech_coreexports__version__, andcheck_rust()compares it. The two are separate distributions built from one repository, so an extension from one revision can sit beside aleechfrom another — and that pairing doesn't raise, it produces different numbers. It is how #176 stayed hidden (new Rust, old serial driver).check_rust()previously printed a bareleech_corewith no version at all:and on a mismatch it now names both halves and says which to rebuild — including the case where the stale half is leech's own editable metadata, which goes out of date after any version bump until reinstalled. (That case is real: it fired on me mid-development, which is why the message covers it.)
3. The release process bumps both and re-verifies
check_rust()afterwards (.claude/commands/release.md), so it cannot drift again by omission.Tests
tests/test_rust_version_pairing.py, 5 cases: the declared versions agree in the source tree (no install needed);rust/pyproject.tomldefers rather than pinning a third copy; the extension exports a version at all; no mismatch in this environment; and the installed extension matches the source tree — that last one being the stale-build hazard itself.1001 passed / 27 skipped. ruff (0.16.1),
ty,cargo fmt,clippy -D warningsclean.Patch-level, no behaviour change — happy to fold it into whatever the next release is rather than tagging for it.