Cargo should support the idea of a parameterized crate. Library crates would declare usage of a parameter with a given default. Binary crates would then give these parameters values which would affect the full build graph.
The crate ecosystem should not need to fragment because of conceptually similar and mutually exclusive crates.
Basically any crate that uses the current feature flags functionality to alter the internals in a mutually exclusive manner would benefit from this.
Cargo.toml would add a section titled
params written as follows:
[params] name = "value"
For a library crate the
value is a default if left unspecified by a downstream crate.
For a binary crate the
value, is the value, and this applies to all crates in the full graph with a matching parameter name.
This does mean that parameter names are global. I'm optimistic about our ecosystem and think we'll collectively decide parameter names to use that make sense.
# Cargo.toml # [...] [params] tls = "native-tls" runtime = "async-std" [target.'cfg(param(tls = "native-tls"))'.dependencies] native-tls = "*" [target.'cfg(param(tls = "rustls"))'.dependencies] rustls = "*" [target.'cfg(param(runtime = "async-std"))'.dependencies] async-std = "*" [target.'cfg(param(runtime = "tokio"))'.dependencies] tokio = "*"
# Cargo.toml [dependencies] async-std = "*" foo = "*" [params] runtime = "async-std" tls = "native-tls"
Can we make declaring parameter-specific dependencies nicer?
I'm not completely sold on most of the details in this. I just think we need something similar to this to address a growing number of areas that need to configure crates in a common and complete fashion.