Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable features on an indirect dependency exposed via public API #8413

Closed
jhpratt opened this issue Jun 26, 2020 · 4 comments
Closed

Enable features on an indirect dependency exposed via public API #8413

jhpratt opened this issue Jun 26, 2020 · 4 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

Comments

@jhpratt
Copy link
Member

jhpratt commented Jun 26, 2020

Describe the problem you are trying to solve
Enable a feature on an indirect dependency (that is exposed in public API)

Describe the solution you'd like
Something like the following?

sha2 = { version = "0.9", features = ["digest/more_lengths"] }

This would require explicit knowledge of the dependencies. This is admittedly not the best of ideas, but could be limited to situations where the type is only in the public API. I've no idea how that would interact with Cargo, however.

Notes
This would be analogous to enabling features of direct dependencies in a crate's features listing, though it wouldn't require the intermediate crate to re-export features.

@jhpratt jhpratt added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Jun 26, 2020
@ehuss
Copy link
Contributor

ehuss commented Jul 29, 2020

I think for now it is intentional that this is not allowed. Features of transitive dependencies are intended to be private implementation details, not exposed as part of the API unless explicitly re-exported by the package.

In this example, if you want to enable features on the digest package, you can explicitly list it as a dependency within your own package.

Closing as this is intended behavior, and there are other ways to express the desired features. I realize controlling features of deep dependencies can sometimes be awkward, but I don't think this is the approach we would likely go with.
cc #2821 #3058

@ehuss ehuss closed this as completed Jul 29, 2020
@bergkvist
Copy link

I just ran into this issue because I wanted to build a project as wasm. The project had the following dependency:

rand_core = { version = "0.6.4", features = ["getrandom"] }

This gives me the following error:

Compiling getrandom v0.2.10
error: the wasm*-unknown-unknown targets are not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support

Naturally, I then try to enable the js-feature in getrandom:

rand_core = { version = "0.6.4", features = ["getrandom", "getrandom/js"] }

But this gives me the error message:

error: failed to parse manifest at `/home/tobias/unrepoed/threshold-ecdsa-dkls-wasm/Cargo.toml`

Caused by:
  feature `getrandom/js` in dependency `rand_core` is not allowed to contain slashes
  If you want to enable features of a transitive dependency, the direct dependency needs to re-export those features from the `[features]` table.

Most package maintainers won't check what features exist in all their dependencies so that they can re-export the useful ones.

@bergkvist
Copy link

While the above would be an intuitive and convenient way of specifying transitive dependency features, the workaround in my case was to explicitly specify the transitive dependency:

rand_core = { version = "0.6.4", features = ["getrandom"] }
getrandom = { version = "*", features = ["js"] }

@epage
Copy link
Contributor

epage commented Oct 26, 2023

FYI part of this confusion comes from a dependencies being implicitly treated as features. We are going to be removing support for that in the 2024 edition. See rust-lang/rfcs#3491

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Projects
None yet
Development

No branches or pull requests

4 participants