CARGO_HOME and RUSTUP_HOME should be included in .cargo/env

[Pascalio]

Problem Installing to a custom location works fine with export CARGO_HOME=custom/.cargo export RUSTUP_HOME=custom/.rustup .bashrc is then updated to source custom/.cargo/env. But then, if the latter file doesn't re-export the custom env vars, cargo and the other tools won't recognise the installation path. This was already mentioned here https://github.com/rust-lang/rustup/issues/2656#issuecomment-890401936

Possible Solution(s)

At least if those env vars haven't got their default values, exporting them from .cargo/env should do the trick, shouldn't it?

Notes

Output of rustup --version: rustup 1.24.3 (ce5817a94 2021-05-31) Output of rustup show: Default host: x86_64-unknown-linux-gnu

[kinnison]

This is certainly an interesting idea -- the separation of RUSTUP_HOME and CARGO_HOME is used by a lot of people to permit complex testing and other setups including sharing a RUSTUP_HOME among multiple users on a system. Though much of that is not supported by us, it would behoove us to not immediately break everyone by forcing the variables in the env script.

Perhaps the answer might be to have the script set-if-not-set the variables, and thence use them? E.g.

CARGO_HOME="${CARGO_HOME:-/path/for/cargo/home/during/install}"
RUSTUP_HOME="${RUSTUP_HOME:-/path/for/rustup/home/during/install}"
export CARGO_HOME RUSTUP_HOME

... rest of env...

That'd have the effect you're suggesting, while not overriding the values someone else might set before sourcing the script.

Would that work for you?

[Pascalio]

This would work brilliantly, thank you!

[robsmith11]

I just ran into this as well. The proposed solution makes sense to me.