cargo install is passed through unwrapped, so it invalidates fingerprints shared with wrapped cargo build

[jbellis]

Summary

The cargo shim passes cargo install through to real cargo without the mbx environment (RUSTC_WRAPPER, HOST_CC, CC, ...), but wraps cargo build. When both commands share a target directory, they invalidate each other's fingerprints, and every C-dependency crate rebuilds on each switch.

What I observed

mbx 1.10.1 on Linux (WSL2). A project script ran:

cargo build --release -p foo --bin foo            # wrapped by the shim
cargo install --locked --path foo --target-dir target   # passed through

Each command rebuilt about 30 crates that the other had just built. CARGO_LOG=cargo::core::compiler::fingerprint=info cargo build --release ... after the cargo install reported:

dirty: EnvVarChanged { name: "HOST_CC", old_value: None, new_value: Some("/mnt/optane/mbx-cache/shims/mbx-cc") }

for ring, aws-lc-sys, zstd-sys, libsqlite3-sys, tree-sitter, and then UnitDependencyInfoChanged for everything above them. The cc crate declares rerun-if-env-changed for HOST_CC/CC, so the build-script fingerprints differ between the wrapped and passthrough invocations.

Cause

cargo_proxy_passthrough in crates/mbx/src/cli/shim.rs lists install among the subcommands that skip the shim. cargo install compiles code, and it accepts --target-dir (or CARGO_TARGET_DIR), so it can share a target directory with wrapped builds.

Suggestion

Treat cargo install as a build command, at least when it builds from a path (--path) or when --target-dir/CARGO_TARGET_DIR is set. That gives it the same cache benefits and keeps its fingerprints consistent with cargo build.

If there is a reason install must stay passthrough, documenting it in the README would help. I changed my script to use cargo build plus a copy instead, which fixed the rebuild loop.

[jdx]

Confirmed: the shim passes install through without the cache session, so switching between wrapped builds and unwrapped installs changes HOST_CC and invalidates build-script fingerprints.

Opened #455 to wrap cargo install --path and resolve the installed package's workspace/configuration even when called from another directory. It preserves shared target directories selected by flags or environment variables. Registry/git installs remain passthrough for now.

The regression test runs build → install → build and checks that the build script runs only once, including installs launched outside the package directory. The full mise run ci gate passes locally.

Until the fix is released, running this from the package directory is another workaround that retains Cargo's installation behavior:

mbx install --locked --path . --target-dir target