-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Comments
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 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. |
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:
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:
Most package maintainers won't check what features exist in all their dependencies so that they can re-export the useful ones. |
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"] } |
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 |
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?
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.
The text was updated successfully, but these errors were encountered: