New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Config support for controlling MSRV-aware resolver #13540
Comments
The RFC proposed [build]
resolver.precedence = "rust-version" # Default with `v3` with the following values (on first release)
Future possibilities
|
For Like with Something like: [resolver]
maximum = <true|false>
rust-version = <true|false|manifest|toolchain|<X>.<Y>.<Z>>
# yanked = <allow|ignore>
# prerelease = <allow|ignore> This would also give control over #13290, #4225 We can have a separate Thoughts
This leads to something like [resolver]
maximum = <true|false>
incompatible-rust-version = <deny|discourage|allow>
yanked = <deny|discourage|allow>
prerelease = <deny|discourage|allow>
rust-version = <workspace|toolchain|<X>.<Y>.<Z>>
|
I wonder if, instead of |
Talking this through with @Eh2406
There isn't really much pushing us one direction or the other, so one way to look at this is which way is easier to evolve. Having fewer fields makes it so we can change it so that field sets defaults on the others. Having more fields makes that a little messier. Current proposal [resolver]
precedence = "<maximum|rust-version>"
# precedence = "<maximum|rust-version|minimum>"
# future: rust-version = "<workspace|toolchain|<X>.<Y>.<Z>" |
This will hopefully help when merging between CLI and config with rust-lang#13540.
refactor: Track when MSRV is explicitly set, either way ### What does this PR try to resolve? This will hopefully help when merging between CLI and config with #13540. ### How should we test and review this PR? ### Additional information
refactor(config): Consistently use kebab-case This shouldn't change the behavior but makes it safer if - We add new fields where it will matter - Copy/paste these for new structs I did not change things related to the Index because we are already stuck with that case (whether we want it or not) Came across this when working on #13540 and almost made the mistake of copying what was already there
This is a part of rust-lang#13540 which is a party of rust-lang#9930. The config is `resolver.something-like-precedence` with values: - `something-like-maximum` (default) - `something-like-rust-version` This is punting on the actual config schema so we can implement `package.resolver` and `edition = "2024"` support as we want the MSRV-aware resolver available without `cargo_features`.
This is a part of rust-lang#13540 which is a party of rust-lang#9930. The config is `resolver.something-like-precedence` with values: - `something-like-maximum` (default) - `something-like-rust-version` This is punting on the actual config schema so we can implement `package.resolver` and `edition = "2024"` support as we want the MSRV-aware resolver available without `cargo_features`.
This is a part of rust-lang#13540 which is a party of rust-lang#9930. The config is `resolver.something-like-precedence` with values: - `something-like-maximum` (default) - `something-like-rust-version` This is punting on the actual config schema so we can implement `package.resolver` and `edition = "2024"` support as we want the MSRV-aware resolver available without `cargo_features`.
fix(msrv): Put MSRV-aware resolver behind a config ### What does this PR try to resolve? This is a part of #13540 which is a party of #9930. The config is `resolver.something-like-precedence` with values: - `something-like-maximum` (default) - `something-like-rust-version` This is punting on the actual config schema so we can implement `package.resolver` and `edition = "2024"` support as we want the MSRV-aware resolver available without `cargo_features`. ### How should we test and review this PR? One of the included test cases shows a bug with `cargo install`. Resolving that will be tracked in #9930 ### Additional information
Split out of #9930 for RFC #3537 for a more focused conversation
We need a config field but this was left undefined in the RFC
The text was updated successfully, but these errors were encountered: