Features and dependencies implied by optional dependencies

[burdges]

At present, optional dependencies cannot imply features or dependencies: w3f/schnorrkel#65 (comment)

You cannot specify implications in the [features] section, due to the error "features and dependencies cannot have the same name". You also cannot specify implications in the [dependencies] section, due to the error "feature names may not contain slashes"

[dependencies.getrandom]
version = "0.2.2"
default-features = false
optional = true
features = ["rand_core/getrandom"] # Invalid

As cargo features are additive, there always exists a solution of an ultimate consumer crate specifying all features for all dependencies, but crate hierarchies could make this quite confusing for the ultimate consumer crate.

There is another hacky solution of freeing up dependency names for features by renaming dependencies using package =, but this should be considered bad practice.

As the hacky solution works, there probably no good reason for the above behavior, so presumably cargo should allow specifying implications in either the [features] or [dependencies] sections.

If there is a good reason not to draw implications from dependencies, then cargo's documentation should clearly explain why ultimate consumer crates should specify all dependencies, why the hacky solution should not be used, and specify a location where dependencies should describe whatever complex feature logic they require of their dependencies.

I suspect the best answer might be: Allow specifying implications in the [features] section, but cargo documentation should better advise crate authors about when to do or not do this.

As a related note, cargo could make optional dependencies truly global: Imagine crate bar specifies crate baz as an optional dependency, then does bar automatically have the dependency baz activated if another crate foo elsewhere in the dependency tree depends upon baz for unrelated reasons? I think the answer should almost always be yes, but the current answer is seemingly no, and this may be useful in niche situations. It's almost surely better if the answer is yes and the documentation explains a work around using package =.

[ehuss]

Can you try out namespaced features and see if it addresses your needs?

[burdges]

Appears so.. I'll close this. :)

I wont use namespaced features right away since they are unstable. I'm also now unsure if my use case was optimal or if consumers users should anyways delve into the getrandom dependency of rand_core works for wasm-bindgen.