Several users of Cargo want the ability to build a set of unrelated Cargo packages (i.e., not a workspace) with a tight control over crates.io dependencies. Tight control, in particular, means:

• the desire to white list and audit crates.io dependencies.
• sharing as much versions as possible for all packages.

Currently, it is possible to achieve a similar effect by abusing workspace, but there's a feeling that a more first-class solution is required.

Case studies

1. Google's Fuchsia. They use a single enormous workspace for all their Rust crates, and invoke cargo-vendor on that: https://fuchsia.googlesource.com/third_party/rust-crates/
2. Facebook has a single pseudo Cargo.toml with all their 3rd-party dependencies. They invoke Cargo on it to download all the crates, and then use Buck to actually build them
3. Debian are in a similar situation (they have a white list of packaged crates, and there's "single version" restriction), but they can't use workspaces, because they must work with existing crates. Not sure how exactly this all works out for them, the relevant docs are here: https://wiki.debian.org/Teams/RustPackaging/Policy
4. Finally Rust itself uses a hack with workspace in rust-lang/rust, which unites rustc cargo and rls, although all of them live in a separate non-workspaced repositories.

Strawman proposal

We can imagine a tool to enable this use-case, which works similar to cargo-vendor, but with a slightly different flavor. Today, cargo-vendor looks at the existing Cargo project, collects all of its dependencies from crates.io and packages them as a directory source.

The proposed tool would start with an explicit "dependencies to vendor" specification file (vendor.toml), which lists a set of packages. This file is the point of audit, and the place to make sure that no duplicate packages are allowed. Then, all other packages would be resolved against these dependencies selection. Corollary: in this system, there's no need for Cargo.locks, because the set of packages is fixed and the resolution is deterministic.

Bonus points:

• determine that the set of vendored packages is consistent, that is, that each vendored package has its dependencies vendored as well.
• nice resolution error messages: "you depend on foo 1.0.0, it is not vendored, but exists on crates.io"
• add ability to generate vendor.toml from a set of leaf Cargo packages.