Features are supposed to be strictly additive for this reason. If it's not your crate, you can maybe depend on two different versions of the crate under different names. Or perhaps one on github and one on crates.io.
#Dependencies use mutually exclusive features
mystic hare
deep marlin
They are all my crates, struggling to see how this will work, even if I publish A and B it will still unify the features for any end user.
The alternative is to put core into A and B (note: there's dozens of these crates, not just two) and turn a 5000 line codebase into a widely duplicated 30 crate monster that will be rough to maintain
Doing it at runtime isn't desirable either.
At this point looking into building dynamic linked libraries, perhaps a way out.
pale falcon
They are all my crates, struggling to see how this will work, even if I publish ...
The thing is, unifying A and B should Just Work
As in, the error is that mutually exclusive features exist at all
mystic hare
Yeah if the thing you're doing is not possible to do additively, then don't use features. Non-additive features is not a feature of features.
deep marlin
How things "should" be and what people want to do aren't always aligned, it's a lot of refactoring and hacks to work around a basic need, I could abandon semver and simply use api versions for each feature instead, the compiler is ok with that. Moving to a dynamic library is also a possibility. Weighing up the options. The API thing feels dirty but is the easiest.
Many popular crates have mutually exclusive features, it's been discussed extensively for 6 years now and the rfc went nowhere: https://internals.rust-lang.org/t/pre-rfc-cargo-mutually-exclusive-features/13182
