cargo vendor is benevolently disruptive #15740
Description
Summary
cargo vendor claims to mirror all dependencies into a specified directory. In practice, it silently strips files it deems unnecessary, creating a mismatch between what's published and what's vendored.
This issue invites discussion on whether cargo vendor should more faithfully mirror published crates.
Documentation vs. Behavior
The documented purpose of cargo vendor is to:
[mirror] all [...] dependencies for a project into the specified directory
It further promises:
After this command completes the vendor directory [...] will contain all remote sources from dependencies specified.
However, in practice, cargo vendor applies its own filtering rules—stripping files it deems unnecessary. This creates a silent contract violation: clients no longer consume the crate as published, but a curated approximation.
Real-World Impact
This surfaced in a real issue, where publisher and consumer expectations diverged due to cargo vendor's uncertain sense of purpose.
The Root Problem
What gets published isn’t always what gets vendored.
Proposed Direction
To address this inconsistency, a more tractable approach would be for cargo vendor to mirror published crates as-is. If a file is part of the published crate, it belongs in the vendor directory—no silent omissions, no editorial decisions.
For crates sourced from Git repositories, any stripping should be explicit and opt-in.
Open Questions
Would existing users of cargo vendor object to this change? If so, understanding the reasons would be helpful.
This report invites discussion on preserving cargo vendor's utility while addressing its disruptive tendency to reshape crates in unexpected ways.