Features cannot enable/disable features of dependencies

[lilyball]

According to the documentation on features, a dependency can have its features specified with the features key (although this is not documented in the actual dependencies section doc). However, it looks like there's no way for a feature to modify the feature list of an existing dependency, only to enable an optional dependency.

If I have a dependency with a feature, and I want to expose that feature as a feature of my own package, I don't see any way to do this. I can't use two dependencies with separate feature lists because a feature cannot disable a dependency. And there's no syntax for a feature to modify the feature list of a dependency.

This seems potentially very problematic to me. Ultimately, I think it's a consequence of features being designed far too heavily as merely toggles for optional dependencies. I think features need to have more control than just turning on optional dependencies. Yes, there's also a --cfg flag, but that doesn't help here either. In #385 I wrote two long comments with my thoughts on the feature design, which got no response. Admittedly it was pretty late in the process, but I still think it's important feedback. With the first feature syntax I suggested, there's plenty of room there to add extra power to features, such as the ability to disable dependencies, or to modify the feature list of a dependency. FWIW I think disabling dependencies might also be important, as I can imagine plenty of reasons why a library might want to have a feature to enable a rarely-used alternative implementation of something, which would need to disable any dependencies used by the disabled default implementation.

[alexcrichton]

I discussed this with @wycats offline a bit, and he was under the impression that this should indeed be possible, and it may have fallen through the cracks in one of the multiple iterations of features. He also says he'll look into this soon.

I'll also note that at the time features were designed we didn't have anything like package id specifications, but now with them we have the ability to uniquely identify an upstream package.

[alexcrichton]

I talked with @wycats a bit today, and I wanted to run this by you before working more on it to make sure it addresses your concerns. We ended up concluding that the crucial feature missing was "reexporting features", basically what you're asking for here I think.

The idea would be to enable a feature of a package to enable an arbitrary feature of a dependency, like so:

[package]
name = "my-package"

[features]
foo = ["bar/baz"]

[dependencies.bar]
optional = true
...

Here the foo feature of my-package enables both the bar dependency and the baz feature of bar. This should solve problem as stated in the title of this issue, but does that sound like it will address your concerns?

[jonhoo]

How would this be used to enable multiple features of bar?

foo = ["bar/baz/qux"]

or

foo = ["bar/baz", "bar/qux"]

[sfackler]

The second.

[jhpratt]

Still doesn't look like it's possible to disable a feature? I'm trying to set up a crate to have a "std" feature, which would indicate that "serde/alloc" is not enabled. For current compilers, this isn't an issue, but my goal is to provide support back to 1.34.0, before alloc was stabilized.

@sfackler perhaps?

[lilyball]

This particular issue was about controlling features of indirect dependencies. I do not believe there's any way to disable features in general (except for the flag to avoid enabling default features). I'm actually surprised that I can't find an issue specifically about this. I too have run into this problem, where I'd like to say "give me default features except for foo" but instead I have to say "give me bar and baz" and hope that the list of default features doesn't change without my notice.