Respect rust-version when selecting a version for cargo install

[epage]

When running cargo install foo, if my rust version is too old, I'll get compilation errors. If the failing crate sets rust-version, then I'll get a nice error message about it but no path forward for fixing it. #10891 adds a path forward for cargo install when the failure is in a dependency but not when its in the crate itself that is being installed.

Ideally, cargo install will select an older version (with a warning) that is compatible with my toolchain. As a step back from the ideal, I'd get an error with corrective steps (ideally, telling me what version to use).

[epage]

This is blocked on rust-version being in the registry

[8573]

While I generally very much support supporting older Rust versions, I worry about how this would (not silently but) quietly give users insecure versions of programs, in the absence of either integration with RustSec or a culture of yanking insecure versions (which I would hope would be blocked on having a way to bypass yankedness for e.g. git bisect).

[epage]

Our choices are

• Error and let the user figure it out (current behavior)
• Error and tell the user how to resolve it
  • This is included as an alternative in this issue
  • This puts it in the users hands for deciding what is safe for them
  • We are still leaving a road hump along the users path to accomplishing their goal, souring their opinion of the ecosystem and possibly being the part that broke their will to continue experimenting with the solution (which will include the common refrain "why is it erroring instead of just doing it")
• Auto-select a compatible version
  • This is included as the primary proposed solution to this issue
  • The user might be surprised at the version used and lack of features
  • The crate version might have vulnerabilities that affect the user

Maybe I'm missing some use cases but I personally have little sympathy for the security side of this. If the error just leads them to selecting an old version anyways, did we really help them with security? How do we know the newest version is any more secure than the older version? This also isn't too different than if someone had cargo installed things previously.

[cassaundra]

Thoughts I had from a discussion with Ed:

My inclination here is to have cargo install still error, but provide a more useful suggestion. I see a couple of problems with auto-selecting a compatible version:

• Most users are running the latest Rust stable/nightly installed via rustup (per 2021 survey), so an out-of-date compiler is more likely to signal to the user that they should upgrade their installation, rather than install an older version of a package.
• cargo install is pretty noisy already, so users might miss the warning.
  • The warning could be put at the end, but by that time the package has already been installed.
  • Even if made less noisy, the warning does not give the user much time to decide what to do.

Improving the error instead helps the average user (instructing them to upgrade their Rust version), but also the less common user (giving them a path forward to install with their current Rust version).

[epage]

"programs you run" is a little different than "project dependencies" and can more likely be ahead.

I also understand the problem of cargo installs output. In general, I wonder if we can do things to shrink our build and test output but that is outside of the scope of this.

Telling the user what version they can install would be a good first step for improving the error message. As that is just UX, we can do that without putting it behind the -Zmsrv-policy feature flag. We can always explore auto-selecting for cargo install in the future.

[epage]

FYI #12553 should make further MSRV work a bit easier

[charles-r-earp]

Telling the user what version they can install would be a good first step for improving the error message. As that is just UX, we can do that without putting it behind the -Zmsrv-policy feature flag. We can always explore auto-selecting for cargo install in the future.

Is it possible to implement cargo +nightly install -Z msrv-policy?

Will this be the default when stable, or is it opt in, behind resolver 3 (#9930)?

[epage]

cargo install was left out of scope for the MSRV-aware Cargo work, besides the error improvement mentioned earlier, as there were additional design concerns to be worked out and we didn't want to smaller improvement on this.