Set MSRV of home crate to 1.71

[nicoburns]

What does this PR try to resolve?

Despite not being intended for external use, 667 crates depend directly on home. It would therefore be nice if it could be more conservative with MSRV than the other crates in this repo. This crate will compile with Rust 1.71 without any code changes, so I've set it to that.

Lower than 1.71 is blocked by #15360 (this crate could compile with lower MSRV than that, but dependencies of crates in this workspace use dep: syntax so cargo doesn't even get that far)

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

Please see the discussion in #13270. Since then, the MSRV-aware resolver has been released as well which won't help if your development version is your MSRV but those cases are likely rare.

[nicoburns]

@epage I don't see how the MSRV-aware resolver helps here (until the MSRV of one's crate is greater than 1.84). Cargo.lock files from libraries don't apply to crates that depend on that library, so even if I apply an MSRV-aware resolution to my dependencies, then the end users of my crate will still get incompatible version resolved unless they are also using the MSRV-aware solver which they obviously won't be able to do if they need a lower MSRV.

I could pin a lower version of each dependency using = in Cargo.toml but I don't think there's an automated way to do that? (and I'd have to do it proactively for every dependency if I wanted to avoid my own MSRV being silently bumped when a dependency updates their MSRV). And even then, that wouldn't necessarily work for transitive dependencies.

Am I missing something?

I would also ask: is there really a meaningful cost to cargo of doing this? No code changes are required. It's literally just a case of not setting the rust-version key in the metadata to an artificially high version.

[epage]

@epage I don't see how the MSRV-aware resolver helps here (until the MSRV of one's crate is greater than 1.84). Cargo.lock files from libraries don't apply to crates that depend on that library, so even if I apply an MSRV-aware resolution to my dependencies, then the end users of my crate will still get incompatible version resolved unless they are also using the MSRV-aware solver which they obviously won't be able to do if they need a lower MSRV.

The interface for enabling the MSRV-aware resolver was intentionally designed to not require an MSRV bump. It only requires that you update your development version of Cargo and use that when generating a Cargo.lock. This works for people who can use a regular toolchain to develop locally and then deploy using a specific toolchain (e.g. from yocto linux). If someone is doing development on a Linux distribution with an old version, then that won't work. This is most likely to happen with desktop Linux distributions. The general vibe I get from the team is that desktop Linux rust is really meant for building the distribution and people should be using rustup otherwise. iirc distributions like Debian are now or soon will be offering rustup.

I could pin a lower version of each dependency using = in Cargo.toml but I don't think there's an automated way to do that?

Doing that, especially in libraries, is also harmful to the ecosystem as it can cause incompatibilities between packages. Cargo.lock is the right way to pin dependency versions and that can be managed via cargo update --precise

(and I'd have to do it proactively for every dependency if I wanted to avoid my own MSRV being silently bumped when a dependency updates their MSRV). And even then, that wouldn't necessarily work for transitive dependencies.

Yes, the MSRV experience for pre-MSRV-aware resolver is not great. This is why I put so much emphasis on getting that work done.

I would also ask: is there really a meaningful cost to cargo of doing this? No code changes are required. It's literally just a case of not setting the rust-version key in the metadata to an artificially high version.

This is not a new argument and it is not productive to re-litigate decisions with each new person who is concerned over something. I'd recommend looking over the discussion in #13270 and our MSRV documentation which we wrote after that PR