Repository navigation
Rust: check in Cargo.toml with a literal version - #58
Merged
Merged
Conversation
The crate's Cargo.toml was generated on every invocation by a wrapper script that stamped the package version from the nearest git tag. Check the manifest in directly, with the current release version (0.10.0) as a literal, and call plain cargo at every call site: CI, the CTest cargo_test, and the Dockerfile test stage (which no longer needs the checkout's .git copied in just so the wrapper could read the tag). The crates.io smoke-test crate gets the same treatment: its checked-in manifest pins the current published release exactly, and the release smoke workflow rewrites that pin to the version under test. With the version a literal in the manifest, the committed Cargo.lock's root entry agrees with it in every checkout, and a release version bump is a deliberate manifest edit followed by a lock refresh.
The linux-so and macOS jobs stage the freshly built library into bindings/rust/lib/ and verify it appears in the package file list. The library is uncommitted by design, and cargo package's version control check now rejects it: with the manifest checked in, cargo takes its git-based listing path and counts the planted library as an uncommitted change. (While the manifest was generated, its .gitignore entry kept cargo on the non-git listing path, which has no such check.) Pass --allow-dirty, cargo's switch for including uncommitted changes, at both call sites.
The git tag is the version source of truth; the checked-in version is bookkeeping that is stamped from the tag only in the publish checkout. Record this at the manifest's version, and note that the smoke-test pin is rewritten by the release-smoke workflow.
The checked-in crate version is now 0.0.0: it is only ever overwritten by the release stamp, so a real-looking value invited confusion with the current release. The manifest comment says so. Also note beside each cargo package --list call in CI why --allow-dirty is there: the staged library is git-ignored but named in the manifest's include list, so the version-control check would otherwise reject it.
The grep after the sed only verified that some genomicsqlite line exists, so a sed miss (for example drifted spacing in the checked-in manifest) would pass the step and go on to test the wrong version. Match the exact expected line instead.
The comment told readers to refresh Cargo.lock as an early release step. Pin refreshes are ordinary dependency work on their own cadence, and the crate version is stamped at publish time; the lock is not a release step.
Shorten the manifest release-versioning block, and drop the date and shorthand from the Cargo.lock note in .gitignore. The mechanism described is unchanged.
The comment led with the staged library and never mentioned the publish-time version stamp, which is the reason this crate is packaged from dirty trees at all. Lead with the design; the staged library is the local trigger.
mlin
marked this pull request as ready for review
November 8, 2026 00:40
Its genomicsqlite pin is rewritten by the release-smoke workflow in every real use, so the checked-in value is a placeholder like the crate version: 0.0.0.
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
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.
Check in literal Cargo manifests and remove both cargo wrappers and manifest templates. CI, CMake, and Docker now call cargo directly.
Previously, wrapper-generated manifests depended on locally available tags, so agreement with the committed lock varied by checkout. The v0.10.0 lock refresh required special tag handling in CI.
The git tag remains the version source for all five release artifacts. The Rust crate's checked-in version and lock root are
0.0.0. Publishing stamps the tag's version into the publish checkout without requiring a version commit. The committedCargo.lockcontinues to pin dependencies.The standalone smoke crate's pin is also a dummy (
=0.0.0). The release-smoke workflow rewrites that pin to the version under test in its disposable checkout.Verified locally: the Rust 1.75 floor passes with the committed lock; the ceiling passes after updating rusqlite to the newest allowed version. A publish-stamp simulation (
0.0.0→0.10.1) changed only the lock's root version, preserved all dependency pins, and packaged successfully.