Provide hints to cargo a feature may be missing?

help
1

I notice with fancy 3rd party libs sometimes cargo (or rust-analyzer) will provide a hint that a feature flag may be missing.

In my own feature configuration set in the Cargo.toml, I have a lot of optional dependencies in addition to modules gated by features.

How can I help downstream consumers of my libs know they may be missing a feature so that instead of this:

error[E0433]: failed to resolve: use of undeclared crate or module `serde`
 --> /usr/local/cargo/git/checkouts/minecrafty-5dcf38af3ff35e96/a7ac854/zombie/src/operation/json.rs:5:5
  |
5 | use serde::de::DeserializeOwned;
  |     ^^^^^ use of undeclared crate or module `serde`

they see a message closer to:

You may need to set "serde" feature for dependency "zombie"

In my zombie lib, can I provide some sort of compile-time hint to anywhere serde is used? How is this problem handled more gracefully so that people aren't left wall-banging there head over a dependency they're frustratingly certain exists?

2

This compilation error indicates a bug in your library’s feature setup. You should arrange so that, for each feature, it enables both the code in your library and the dependencies for that code to work. The user should never have to enable an additional feature to get your library to compile without errors.[1]

For example, you might have:

[features]
json = ["dep:serde"]

[dependencies]
serde = { version = "1.0.219", optional = true }

#[cfg(feature = "json")]
mod json {
    use serde::de::DeserializeOwned;

    ...
}

This way the use will never fail to compile, because in all the situations where it is compiled, the serde dependency is also present.

  1. Except in special cases where it’s necessary to have requirements like “enable at least one of these features”, but those should also be avoided as much as possible. ↩︎

8 Likes