Repository navigation
A more robust post-install environment setup #1881
Description
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/envto 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
Activity
kinnison commentedon May 28, 2019
I think this is very reasonable. Currently we add
export PATH="/expanded/cargo/home/bin:$PATHto each such file. I agree with the inclusion of.bashrcthough I'd argue that.zshrcand.zsh_profilecould all be dropped in favour of.zshenvwhich is always sourced even in non-interactive cases.Regarding the expansion or otherwise of
CARGO_HOMEI suppose we could add a snippet of:That would cover all shells which are at least POSIX compatible, including ones which don't actually support
export VAR=valuethough 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_HOMEstuff, so if you don't want to pursue that here, just pretend I offered:brson commentedon May 28, 2019
Ah, I removed my comments about
$CARGO_HOMEthat @kinnison responded to, but basically, I said, that rustup-init obeys$CARGO_HOMEand writes its expanded definition into the dotfiles, meaning that post-install, that is permanently the home of cargo, and$CARGO_HOMEcan'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_HOMEis just a directive for where the user prefers it to live, and the paths expanded in the dotfiles will maintain that primary install.Use safest way to set path, as rustup should be doing it
Use safest way to set path, as rustup should be doing it
rbtcollins commentedon Mar 1, 2020
@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 commentedon Mar 8, 2020
This is being worked on, also.