A more robust post-install environment setup

[brson]

This is based on my recent frustration reinstalling WSL and rustup, and subsequent discussion here: #975 (comment)

The rustup install experience is still frustrating. Ever since modifying rustup to modify only .profile instead of the rc files, I don't particularly know how to get cargo to work on my WSL install, and always end up modifying .bashrc.

I don't know when or if .profile is executed by default on WSL, but some cursory googling suggests it is not. I have only just today figured out how to open a WSL terminal to a login shell.

And I suspect many users don't understand the difference between a login shell and non-login shell. That they have to log out of their GUI and back in (as I understand it - or understand what a login shell is and launch one) is obnoxious. I just want to start working in Rust immediately.

I know that the "correct" thing to do is to modify .profile, .bash_profile, and maybe .bash_login (which is not modified today), but I don't think it provides a good experience, and I'd like to propose a more rubust solution.

• Change ~/.cargo/env to conditionally modify $PATH if it is not already set.
• At install, source that file from .profile, .bash_profile, .bash_login, .bashrc, and .zshrc, any of those that exist.
• At uninstall, reverse those changes as is done today.

For purists who don't like this, they can configure the installer to not touch their dotfiles.

It was additionally suggested in the above mentioned thread that the rustup installer itself could immediately spawn a new shell so that the current terminal works immediately. I think this is worth considering. (Edit: though there are challenges here with non-interactive installs, installs that prefer non-bash environments, maybe others. It would also need to be a config option).

It is embarrassing that rust does not "just work" after install. It is the first impression of the rust experience.

Edit: removed some unrelated comments about $CARGO_HOME

[kinnison]

I think this is very reasonable. Currently we add export PATH="/expanded/cargo/home/bin:$PATH to each such file. I agree with the inclusion of .bashrc though I'd argue that .zshrc and .zsh_profile could all be dropped in favour of .zshenv which is always sourced even in non-interactive cases.

Regarding the expansion or otherwise of CARGO_HOME I suppose we could add a snippet of:

### BEGIN:RUSTUP Added by rustup, do not change this section by hand
if test "x$CARGO_HOME" = "x"; then
    CARGO_HOME="/expanded/cargo/home/from/install/time"
    export CARGO_HOME
fi
if ! command -v rustup >/dev/null 2>&1; then
    PATH="${CARGO_HOME}/bin:$PATH"
    export PATH
fi
### END:RUSTUP Added by rustup, do not change this section by hand

That would cover all shells which are at least POSIX compatible, including ones which don't actually support export VAR=value though those seem few and far between so I'd be prepared to drop that separation.

We'd need to convert from the old string to the new one, but the markers would make it clearer what was going on perhaps?

I don't like the idea of spawning a new shell immediately because that would play badly with some people's terminal expectations. I think it's sufficient to make it clear what to do to make the current shell work (which we print out anyway) and to make it more likely that a newly opened shell will do the right thing via your points about the RC files.

I think, since I started writing this, you removed mention of the $CARGO_HOME stuff, so if you don't want to pursue that here, just pretend I offered:

### BEGIN:RUSTUP Added by rustup, do not change this section by hand
if ! command -v rustup >/dev/null 2>&1; then
    PATH="/cargo/home/from/install/time/bin:$PATH"
    export PATH
fi
### END:RUSTUP Added by rustup, do not change this section by hand

[brson]

Ah, I removed my comments about $CARGO_HOME that @kinnison responded to, but basically, I said, that rustup-init obeys $CARGO_HOME and writes its expanded definition into the dotfiles, meaning that post-install, that is permanently the home of cargo, and $CARGO_HOME can't usefully be set in the init files.

On the other hand though, I'm not sure if that's the best use of $CARGO_HOME. It's more useful for creating self-contained cargo installs for special purposes. At install time, for the "main" install, $CARGO_HOME is just a directive for where the user prefers it to live, and the paths expanded in the dotfiles will maintain that primary install.

[rbtcollins]

@98982872 if that is after creating a new login session then please open a new ticket about installation on your distro. This ticket is about the requirement for starting new login sessions before rustup is actually usable.

[kinnison]

I wish Rust had a snap package.

This is being worked on, also.