Introduce --all-features flag to cargo vendor

[collinoc]

Problem

When using cargo vendor, the only transitive dependencies that get vendored are the ones of enabled features at the original time of vendoring. This is an issue when a user that only has access to the vendored crates later tries to enable a feature of a crate that was not originally enabled. Example flow:

1. cargo add tokio --features full
2. cargo vendor vendor_dir
3. User uses vendored directory for source replacement
4. User tries to use tokio features behind mio feature (not under full feature flag), but transitive dependencies were not included in vendored directory and is unable to build

Proposed Solution

I propose introducing an --all-features flag to cargo vendor that would vendor all optional dependencies behind any feature flags for any dependencies of a project. This is simply a convenience so that not all features have to be manually specified.

Another possibility would be to have different levels for vendoring for "all features":

• --all-features=top would only vendor dependencies for all features for top level dependencies (all optional dependencies for tokio in previous example)
• --all-features=recursive would recursively vendor dependencies for all features for all dependencies (all optional depencies for tokio and mio and so on, in previous example)

Notes

Cargo seems to have an all-features flag that is similar to what I am thinking of.

I'd be glad to contribute to this! 😃

[tobywf]

(Please let me know if this isn't the right place to discuss this.)

Especially the recursive option could be quite valuable. Cargo.lock doesn't record disabled optional dependencies, and there's a wish for even more minimal Cargo.lock files (#10801). However, e.g. cargo build requires all optional dependencies to be "present" (#4544). Currently, to my knowledge it's quite difficult to get a fully resolved graph with weak optional dependencies? If this were implemented, not only would cargo vendor benefit, but tools like cargo-local-registry or 3rd party tooling could re-use the logic until/if #4544 is solved.

There's already something called Workspace::require_optional_deps, which you'd expect to do something like this, but from my testing it doesn't.

[epage]

Cargo seems to have an all-features flag that is similar to what I am thinking of.

cargo check --all-features means "enable all features for the selected packages".

I'm assuming we already vendor dependencies in that mode because we generate lockfiles in that mode. iiuc whats being wanted here is instead "enable all features for all of my transitive dependencies". I believe cargo vendor is currently more of a Cargo.lock snapshotting tool. We'd either need to extend what gets included in Cargo.lock or to extend it beyond Cargo.lock snapshotting. The latter runs the risk of changing versions of transitive dependencies on every run.

If you are ok with cargo add, then #15019 may serve as a viable alternative (cargo add automatically vendoring any new dependencies).

[ehuss]

Thanks for the suggestion! The cargo team discussed this and decided to close for now. We had some concerns about the complexity of implementing such a feature since cargo wouldn't know which versions of those optional dependencies to include (in particular, versions that would result in a valid resolve). There were also concerns about vendoring things that weren't already tracked in Cargo.lock. A minor concern was also the specific name of the flag, which has a different meaning in other contexts.

We recommend that if you are interested to try to create an external command that is capable of generating those extra vendored packages, or just create a dummy workspace that has all dependencies with all features. With external tooling you can iterate and gather feedback on it.