# Pre-RFC: Cargo mutually exclusive features

**URL:** <https://internals.rust-lang.org/t/pre-rfc-cargo-mutually-exclusive-features/13182>\
**Category:** cargo\
**Created:** [October 9, 2020, 10:38am UTC](https://internals.rust-lang.org/t/pre-rfc-cargo-mutually-exclusive-features/13182 "2020-10-09T10:38:45Z")\
**Posts on this page:** 1\
**Showing post:** 27

<div class="post-metadata">

**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\
**Post date:** [October 21, 2020, 2:08pm UTC](https://internals.rust-lang.org/t/pre-rfc-cargo-mutually-exclusive-features/13182/27 "2020-10-21T14:08:24Z")

</div>

> [@jsgf](#):
>
> Requiring the binary to have deep enough knowledge of its entire dependency graph in order to set configurations for the whole thing seems unreasonable

This doesn't sound unreasonable to me. Leaf dependencies may need to know which runtime/back-end/OS API to use, but these things aren't just implementation details. They may affect things like operating system compatibility or cause performance issues that affect the whole binary.

Only thing I'm worried about is fragility of such configuration, similarly to how `patch.crates-io` section is fragile and can cease to apply at any time. For example, I may want to make HTTPS requests with a specific implementation of a CA certificate store. I'll configure fooTLS library to use it. But if my requests library changes its dependency to barTLS library at any time, my fooTLS config won't be applicable any more.

---

_[View the full topic](https://internals.rust-lang.org/t/pre-rfc-cargo-mutually-exclusive-features/13182)._