mirror of
https://github.com/rust-lang/cargo.git
synced 2025-09-28 11:20:36 +00:00
80f1a5d0f7
feat(resolver): `-Zdirect-minimal-versions` This is an alternative to `-Zminimal-versions` as discussed in #5657. Problems with `-Zminimal-versions` includes - Requires the root most dependencies to verify it and we then percolate that up the stack. This requires a massive level of cooperation to accomplish and so far there have been mixed results with it to the point that cargo's unstable documentation discourages its use. - Users expect `cargo check -Zminimal-versions` to force resolving to minimal but it doesn't as the default maximal resolve is compatible and requires `cargo update -Zminimal-versions` - Different compatible versions might be selected, breaking interop between crates, changing feature unification, and breaking `-sys` crates without bad `links` `-Zdirect-minimal-versions` instead only applies this rule to your direct dependencies, allowing anyone in the stack to immediately adopt it, independent of everyone else. Special notes - Living up to the name and the existing design, this ignores yanked crates. This makes sense for `^1.1` version requirements but might look weird for `^1.1.1` version requirements as it could select `1.1.2`. - This will error if an indirect dependency requires a newer version. Your version requirement will need to capture what you use **and** all of you dependencies. An alternative design would have tried to merge the result of minimum versions for direct dependencies and maximum versions for indirect dependencies. This would have been complex and led to weird corner cases, making it harder to predict. I also suspect the value gained would be relatively low as you can't verify that version requirement in any other way. - This also means discrepancies between `dependencies` and `dev-dependencies` are errors - The error could be improved to call out that this was from minimal versions but I felt getting this out now and starting to collect feedback was more important. One advantage of this approach over `-Zminimal-versions` is that it removes most of the problems that [cargo-minimal-versions](https://github.com/taiki-e/cargo-minimal-versions) tried to workaround. As for the implementation, this might not be the most elegant solution but it works and we can always iterate and improve on it in the future. - We keep the state as a `bool` throughout but compensate for that by explicitly creating a variable to abstract away constants - The name changes depending on the context, from `direct_minimal_version` when dealing with the unstable flag to `first_minimal_version` when the concept of "direct" is lost to `first_version` when we split off the ordering concept into a separate variable - Packages that respect `direct_minimal_versions` are determined by whether they are the top-level `summaries` that get past into `resolve` ### What does this PR try to resolve? The primary use case is verifying version requirements to avoid depending on something newer than might be available in a dependent For this to help the MSRV use case, the crate author must directly depend on all indirect dependencies where their latest release has too new of an MSRV but at least they can do so with the `^` operator, rather than `<` and breaking the ecosystem. ### How should we test and review this PR? The first two commits add tests using `-Zminimal-versions`. The commit that adds `-Zdirect-minimal-versions` updates the tests, highlighting the differences in behavior. ### Additional information Potential areas of conversation for stablization - Flag name - Handling of yanked (pick first non-yanked, pick yanked, error) - Quality of error message - Should the package have a "memory" of this flag being set by writing it to the lockfile? Potential future work - Stablize this - Remove `-Zminimal-versions` - Update `cargo publish`s `--verify` step to use this. - The challenge is this won't be using the packaged `Cargo.lock` which probably should also be verified.