Found by a clean-room reviewer running the suite in a fresh environment that had CARGO_TARGET_DIR exported (a shared target directory, which is a common setup for anyone building several Rust repos).
TEST_EXIT=101
... three failures, each: No such file or directory (os error 2)
Unsetting the variable makes it green.
Cause
crates/varve-core/tests/cargo_offline.rs:44 shells out to cargo package and then reads the artifact at a hard-coded relative path:
dir.join("target/package/{name}-{version}.crate")cargo package honours CARGO_TARGET_DIR and writes to that directory instead, so the test looks in a place nothing wrote to.
Why it is worth fixing rather than documenting
The failure does not look like a test-harness problem. It surfaces as a missing .crate file in a test named for offline packaging — i.e. it reads as "varve cannot package itself offline", which is a REQ-BOOTSTRAP-001 property people are meant to trust. A contributor hitting this on a first run has no reason to suspect their environment, and the honest reading of the output is that the product is broken.
Fix
Resolve the package output directory from the environment rather than assuming ./target — read CARGO_TARGET_DIR (falling back to target/), or pass --target-dir explicitly to the cargo package invocation so the test controls where it lands. The latter is more deterministic and does not depend on the ambient value being sane.
Worth checking the sibling tests (corrosion_offline.rs and anything else invoking cargo as a subprocess) for the same assumption while in there.
Not a regression from any current branch — this is long-standing.
Found by a clean-room reviewer running the suite in a fresh environment that had
CARGO_TARGET_DIRexported (a shared target directory, which is a common setup for anyone building several Rust repos).Unsetting the variable makes it green.
Cause
crates/varve-core/tests/cargo_offline.rs:44shells out tocargo packageand then reads the artifact at a hard-coded relative path:cargo packagehonoursCARGO_TARGET_DIRand writes to that directory instead, so the test looks in a place nothing wrote to.Why it is worth fixing rather than documenting
The failure does not look like a test-harness problem. It surfaces as a missing
.cratefile in a test named for offline packaging — i.e. it reads as "varve cannot package itself offline", which is a REQ-BOOTSTRAP-001 property people are meant to trust. A contributor hitting this on a first run has no reason to suspect their environment, and the honest reading of the output is that the product is broken.Fix
Resolve the package output directory from the environment rather than assuming
./target— readCARGO_TARGET_DIR(falling back totarget/), or pass--target-direxplicitly to thecargo packageinvocation so the test controls where it lands. The latter is more deterministic and does not depend on the ambient value being sane.Worth checking the sibling tests (
corrosion_offline.rsand anything else invoking cargo as a subprocess) for the same assumption while in there.Not a regression from any current branch — this is long-standing.