Open nfejzic opened 1 week ago
Thanks for the idea! The Cargo team has recently accepted an RFC extending feature metadata table: https://github.com/rust-lang/cargo/issues/14157. There are future extensions listed in that tracking issue. A similar extension is supporting stable/beta/nightly features: https://github.com/rust-lang/cargo/issues/10881, though that is not identical to this one.
Also #[cfg(version(..))]
and #[cfg(accessible(..))]
are compiler features you may want to pay attention to, which are nice when pairing with this proposal.
That means this is blocked on #14157, and requires an RFC to start with.
Per-feature MSRVs came up in the MSRV RFC. It was one of the motivating cases for why we felt that Cargo shouldn't error if a dependency required a newer MSRV than your package.
For myself though, I would want to better understand the motivations for why there is a per-feature MSRV and would, in general, push back against the idea. imo this adds a lot of user and design complexity and it isn't clear to me that its worth it compared to having just one MSRV or, where possible, splitting the higher MSRV section out into a separate package.
Problem
Hello everyone! Sorry if similar issue already exists, I could not find something like this.
While discussing the MSRV in https://github.com/tqwewe/kameo/issues/76, we figured out that the currently MSRV could be lower, but a certain non-default feature requires the higher version.
Would it be possible for cargo to support package metadata that is feature gated? For example,
rust-version
is set to1.65
per default, but if featurefeat-a
is enabled, that sets therust-version
to1.75
.Proposed Solution
Syntax for dependencies already exists, as described in the Cargo book:
Maybe similar syntax can be used for other tables:
Alternatively, we could extend features to support (inline) tables:
Notes
No response