Mutually exclusive features

[retep998]

In Windows API there is the notion of a family and partitions. Your choice of family is basically which platform you are targeting and there is a choice between WINAPI_FAMILY_DESKTOP_APP WINAPI_FAMILY_PC_APP WINAPI_FAMILY_PHONE_APP WINAPI_FAMILY_SYSTEM and WINAPI_FAMILY_SERVER. Your choice of family in turn enables certain partitions which enable access to certain functionality. At the moment I cannot use cargo features for this because they are not mutually exclusive, so two downstream dependencies could specify different families which is completely wrong. Even if I use a build script to ensure only one such feature is selected, it would be a nightmare to ensure that every single downstream dependency chooses the same family, threading the choice of family feature through long chains of transitive dependencies that shouldn't have to care about that choice.

What I think would work well here is some sort of feature selection that has to choose exactly one option from a closed set, and that choice is controlled by the root crate. All dependencies that are affected by that choice will then need some way to be informed of the choice so they can adjust which functionality to use depending on that choice.

At the moment the only workaround I see is for the user to pass an environment variable while building the project so winapi's build script can read that to choose the family followed by emitting key=value stuff which downstream dependencies can read via build scripts through the DEP_WINAPI_key=value environment variables to emit cfgs to control their own code.

Also, this can also apply to other choices, such as which version of Windows you want to target, newer versions have more functionality that dependencies might want to be able to take advantage of, but the user might also want them to target an older version instead so it can run on more systems.

[Boddlnagg]

I just had this idea, but haven't thought it through yet: To get mutually exclusive features couldn't you just add some piece of code to the crate that is gated on the features that should not be used together and make rustc output some error message that actually points to the problem (do we have something like #error in C, probably a macro?).

This could be considered an ugly workaround, but maybe it allows the greatest flexibility.

[retep998]

@Boddlnagg Suppose the user is working on their project apple which depends on banana which in turn depends on cat which in turn depends on winapi. Now cat is capable of supporting two different winapi families, so how does it deal with this? Suppose it decides to provide two features for each of these options so the user can decide, but wait, the user is not the one depending on cat, it is banana. So banana is now responsible for re-exporting those features, even though it does not use winapi directly, and should not care at all which winapi family is being used. But now realize that winapi has a ton of reverse dependencies and the poor user's apple project ends up depending on a whole messy dependency graph with winapi up many of those branches. Do you really expect every single crate in between apple and winapi to diligently re-export features so that the user can choose which family they want?

Right now the way features work is that foo specifies which features it requires from bar and the user only has any say in this if foo provides its own features to control this, and every single transitive dependency downstream re-exports these features. What I really think we need instead is a way for foo to specify which features it could use from bar, but not necessarily require. Then the user can choose which of those features it wants and foo will be notified in some manner of which features it actually got so it can adjust its code appropriately. Imagine something like hyper where right now if you want to disable the ssl feature (due to that annoying openssl dependency) you have to hope every single crate which depends on hyper, even transitively, re-exports the option to not depend on the ssl feature. If instead each of the crates that directly depends on hyper said it merely could use the ssl feature if it was available, then the user could choose whether or not to enable ssl from a single point and all the reverse dependencies of hyper would be aware of this and adjust accordingly. Without a system like this, I don't think it would be possible to sanely have mutually exclusive features.

[mat8913]

Maybe allow specifying feature conflicts in Cargo.toml, such as:

[dependencies.awesome]
version = "1.3.5"
features = ["!secure-password", "civet"]

Which means this package depends on "awesome" but requires the "secure-password" feature to be disabled.

Also,

[features]
go-faster = []
secure-password = ["!go-faster", "bcrypt"]

means that this package provides features "go-faster" and "secure-password". But if "secure-password" is enabled, "go-faster" must be disabled.

[luser]

I've run into this in practice before with the flate2 crate, which has features to select between using zlib and miniz as the implementation. It's an either-or choice, but nothing in cargo actually ensures that.

Your use case here seems like it's not well-served by features at all, honestly. cargo features as-implemented are allowed to be required by arbitrary crates in the dependency graph, so you'd have to have some way to completely override that. It's more similar to openssl-sys's OPENSSL_STATIC option, which is processed by its build script from the environment, or -Ctarget-feature=+crt-static. That is, it seems like a configuration option that can only be chosen by the crate at the top of the dependency tree which is producing a native binary output.

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!