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.