Support -Zdirect-minimal-versions

[taiki-e]

rust-lang/cargo#11688

[epage]

At least in its current implementation, I think my PR solves most of the problems discussed in this tool. We switched from "resolve down" to "treat direct dependencies as if ^ was =".

• For cargo check, we see if the Cargo.toml is compatible with Cargo.lock. Just like with "resolve up", "resolve down" does not force a re-calculation so long as the versions are still compatible, which is why you needed cargo update. Now, treating direct dependencies as =, the Cargo.lock will be considered incompatible and a new one generated within cargo check, as if you changed the version requirement
• For dev-dependencies, because we treat direct dependencies as =, anything besides the minimal versions will be a resolver error.

I'm not quite understanding the concern with the -p motivation, so I can't speak to that.

[taiki-e]

• For cargo check, we see if the Cargo.toml is compatible with Cargo.lock. Just like with "resolve up", "resolve down" does not force a re-calculation so long as the versions are still compatible, which is why you needed cargo update. Now, treating direct dependencies as =, the Cargo.lock will be considered incompatible and a new one generated within cargo check, as if you changed the version requirement

👍

• For dev-dependencies, because we treat direct dependencies as =, anything besides the minimal versions will be a resolver error.

If dependencies.foo is 1.0.0 and dev-dependencies.foo is 1.0.1 and there are no other dependencies, is the minimal version of foo when running cargo check -Zdirect-minimal-versions will be 1.0.0? Or will it be 1.0.1? If the former, that is the behavior expected by cargo-minimal-versions.

I'm not quite understanding the concern with the -p motivation, so I can't speak to that.

If -p or --workspace or --all flag is passed together with -Zdirect-minimal-versions, does cargo do feature-unification? That is the default behavior of cargo, but not the behavior expected by cargo-minimal-versions, because other crates in the workspace may increase version requirements or specify more features. (e.g., tokio-rs/tokio#4490 (comment))

However, it is fine even if cargo does not provide the behavior expected by the cargo-minimal-versions on this. Because cargo hack + -Zdirect-minimal-versions can provide a similar behavior as the current cargo-minimal-versions if the above two are implemented as expected. (Given that #1 and #6 are planned to be fixed by the cargo-minimal-versions in the future, the advantages of the cargo-minimal-versions are not lost, though.)

[epage]

If dependencies.foo is 1.0.0 and dev-dependencies.foo is 1.0.1 and there are no other dependencies, is the minimal version of foo when running cargo check -Zdirect-minimal-versions will be 1.0.0? Or will it be 1.0.1? If the former, that is the behavior expected by cargo-minimal-versions.

I just checked and this will cause a version conflict error.

If -p or --workspace or --all flag is passed together with -Zdirect-minimal-versions, does cargo do feature-unification? That is the default behavior of cargo, but not the behavior expected by cargo-minimal-versions, because other crates in the workspace may increase version requirements or specify more features. (e.g., tokio-rs/tokio#4490 (comment))

The best guess I have as to what is going on is not that feature-unification isn't taking place but that two different compatible versions of a crate were selected and feature unification happened within those two separate versions. Does that sound right?

If the two different versions were within indirect dependencies, that would behave as cargo normally does, not like -Zminimal-versions. If one of the versions is a direct dependency, then that would be a conflict error.