Use home crate for CARGO_HOME and RUSTUP_HOME

[skilly-lily]

Cargo uses the home crate to determine CARGO_HOME. Rustup could use this crate for HOME, CARGO_HOME, and RUSTUP_HOME.

Fixes #1915

[kinnison]

I think this is okay, but I'd like to think about it a little more before accepting it. It's very similar to a patch I wrote six months ago and then decided not to submit because I wasn't certain it had entirely the same semantics.

[skilly-lily]

I figured that there might be some concern about this, but it was easy enough to try out in any case.

I'll compare the two and see if they are the same. They did look the same at first glance, like it was copied out of this project, but we should confirm.

[kinnison]

Thanks for doing that check.

[skilly-lily]

The unix semantics of dirs::home_dir() match the std::env::home function. The windows semantics match the utils::utils implemetation.

Looks like the rustup_home implementation has a liitle more attached to it than the current one.

After checking, I don't see much value in taking this change, and there is a (very small) risk of some semantic change if it's accepted.

@kinnison: I'll leave this open so you can make a decision, but I no longer think it makes sense to accept this. If you decide against it, just go ahead and close it.

[kinnison]

The value in taking the change would be a reduction in complexity of code in rustup. What is the difference in code which you have detected? It's possible that it's no longer necessary.

[skilly-lily]

A fair point. I took another close look at it:

Switching to the home crate adds support for finding CARGO_HOME/RUSTUP_HOME using pre-existing multirust directories. One notable exception is that CARGO_HOME=.multirust/cargo is special-cased and ignored. The comment explaining this can be found here.

Also, cargo home can be found under the incorrect std::env::home definition, if it exists.

[kinnison]

Hrm, this definitely needs more thought before I can decide. I think I'll need a bit of time to think.

[bors]

☔ The latest upstream changes (presumably #1923) made this pull request unmergeable. Please resolve the merge conflicts.

[brson]

For context, I'm pretty sure that home was identical to rustup when I wrote it (with the purpose of doing a PR like this). Since that time I believe some of rustup's legacy logic, particularly related to multirust, has been deleted. I do not know if any new logic has been added. cc @nrc

I still believe it is appropriate to move this logic out of rustup so that all tools can get the definition correct (e.g. IDE's might want to introspect RUSTUP_HOME or at least be able to tell the user where it is), and so that rustup and cargo agree on the definition of CARGO_HOME.

Note though that home is not an official Rust project and was for a while completely unmaintained. I am happy to add anybody else as a maintainer, or to transfer ownership to somebody more attentive and dedicated than I.

[brson]

Related: https://users.rust-lang.org/t/home-crate-0-4-1-released/31094

[skilly-lily]

@kinnison Let me know if we do want to merge these changes in based on @brson's update. If we do, I'll resolve the Cargo.lock conflict.

[brson]

@lzutao is now a maintainer of the home crate.

[kinnison]

Given @brson's explanation of the situation, and @lzutao's agreement to help with crate maintenance, I am indeed happy for this to be cleaned up for merge. Please do resolve the conflict (remove the .lock change from your commit, rebase onto master, then add the .lock change in a fresh commit) and I'll give things a final gloss check.

[skilly-lily]

@kinnison Resolved. CI error looks to be unrelated to my change, and passes on my ubuntu machine using cargo test --test cli-misc.