Cargo: Optional dependency when a feature is not enabled.

Created on 27 Jul 2015 · 3Comments · Source: rust-lang/cargo

Some libraries can run on stable Rust with degraded performance (e.g. without using NonZero) or limited capabilities (some APIs disabled). The emerging practice seems to be having an unstable or nightly Cargo feature to enable user to opt into using unstable Rust features when they are available.

I’m publishing rust-rc as a work around for std::rc::Weak not being stable yet. At the moment, there doesn’t seem to be a way to have this crate as a dependency by default, but _not_ when the unstable feature is enabled. Could this be added to Cargo?

Note that reversing the default and having a stable feature only moves the problem to dependencies that can/should only be used on unstable Rust.

A-features

Source

SimonSapin

❤2 👍2

Most helpful comment

With the [target.'cfg(...)'.dependencies] syntax, this could be supported simply by allowing cfg(feature = "...") to behave as it does in Rust code:

[target.'cfg(not(feature = "std"))'.dependencies]
hashmap_core = "0.1.2"

Currently, such a section is treated as enabled _regardless_ of feature status, which honestly seems like a bug to me.

eternaleye on 22 Mar 2018

👍8

All 3 comments

I'd also like to have this. In midir, there are multiple backends (ALSA and/or JACK on Linux, CoreMIDI and/or JACK on OSX, WinMM on Windows), and my plan is to have a jack feature flag which enables JACK and disables the other (native) one. I also would like to remove the dependency on ALSA/CoreMIDI in the case of compiling for JACK, so it could even be used if ALSA is not installed on the system.

My first idea was what is requested above, i.e. to simply disable alsa-sys dependency if jack feature is selected.

An alternative to this is to have a default feature (e.g. native), which could be disabled if jack is enabled, and then have platform-specific dependencies for this feature (namely alsa-sys on Linux and CoreMIDI on OSX), using something like [target.x86_64-unknown-linux-gnu.features]. It also seems to be currently impossible to have target platform specific default-feature-sets, which would also solve the problem.

So far I was not able to find a workaround that works without defining platform-dependent dependencies/features in dependent crates, but I may have overlooked something.

Boddlnagg on 11 Aug 2015

With the [target.'cfg(...)'.dependencies] syntax, this could be supported simply by allowing cfg(feature = "...") to behave as it does in Rust code:

[target.'cfg(not(feature = "std"))'.dependencies]
hashmap_core = "0.1.2"

Currently, such a section is treated as enabled _regardless_ of feature status, which honestly seems like a bug to me.

eternaleye on 22 Mar 2018

👍8

Same case for me:

[target.'cfg(not(feature = "std"))'.dependencies]
heapless = "0.2.7"

[features]
default = ["std"]
std = []

I only want the heapless dependency if feature std is not enabled.
heapless works with nightly only, but I want my library to be compatible with stable if std is enabled.

Is the current behaviour a bug or is it intended?