Should Cargo have a real dependency snapshot, not just a lockfile?

I work on Linux machines that are sometimes offline for days, and Cargo’s current pieces help but still feel fragmented. `Cargo.lock` records versions, while `cargo fetch`, `--offline`, and `cargo vendor` cover parts of getting sources locally. None of that is quite a portable dependency snapshot containing cached artifacts, target metadata, toolchain assumptions, and instructions for reproducing the build.

I can see the appeal: an archived snapshot could make a project recoverable when the registry or Git source is unreachable, without treating the network as part of every build. But the archive could become enormous, preserve vulnerable dependencies indefinitely, and still fail on another platform because target-specific dependencies and host tools differ. It might also turn routine updates into archaeology.

Would this be worth formalizing in Cargo, or is a scripted combination of vendoring, toolchain pinning, and CI artifacts better? Disagree, share your workflow, or suggest a cleaner design.

I would separate the archive from the repository. Keep a manifest describing the exact snapshot, store sources and build outputs in content-addressed bundles, and let teams choose which targets to include. The important property is that restoration works without depending on today’s registry layout.

A snapshot is not automatically safer. Freezing known-vulnerable crates can make an incident harder to remediate, especially if teams start treating the bundle as authoritative forever. I would require freshness and vulnerability review metadata, not just hashes.

For small projects I already use `cargo vendor` plus a pinned toolchain and keep the generated directory outside the main repository. It is boring, but boring beats inventing a second package format. My real pain is remembering to refresh it before going offline.

The distinction between “reproducible” and “restorable” matters here. A lockfile can describe resolution without containing the sources or artifacts needed for recovery. I would support a standard snapshot only if its scope and guarantees were stated very narrowly.

Build outputs are the awkward part. They are target-, compiler-, and sometimes host-dependent, so bundling every artifact either explodes storage or creates false confidence. I would snapshot inputs and build instructions, then treat artifacts as optional accelerators.

This sounds like three existing things wearing a new coat: vendor the crates, save the toolchain, write a script. A standard wrapper could be useful, but I am unconvinced the wrapper deserves to become Cargo’s problem.

The operational question is who refreshes it. If nobody owns snapshot rotation, “offline reliable” becomes “offline and permanently stale.” I would want an explicit update job that produces a diff of dependency versions, targets, and security findings.

The enormous-cache objection may be overstated if snapshots are deduplicated and target selection is explicit. The mistake would be making one universal bundle. A server build, an ARM device, and a developer laptop do not need identical cached artifacts.

I would avoid embedding registry credentials, private source URLs, or unverifiable provenance inside the snapshot. Offline use increases the value of local data, so the format should make origin, integrity, and authorization inspectable rather than hiding them in a tarball.

For regulated or isolated environments, an auditable bundle may be easier to approve than a build that silently reaches out to a registry. But procurement will ask whether the format is stable and portable. A project-specific script is hard to govern across many teams.

Make it opt-in and ergonomic. Most developers will not manage a giant archive for ordinary applications, but teams with unreliable networks will gladly pay the complexity cost. The failure mode is forcing everyone to carry the edge case.

One possible compromise: Cargo emits a machine-readable closure containing the lockfile, vendored source checksums, target matrix, toolchain identifiers, and commands. Artifact caches remain separate and disposable. That gives ownership of the recipe without pretending binaries are universal.