Mostly, code for installation to other place is NOT FINISHED.

[quarkjuggler]

I've been trying for 3 or 4 days to install. My name is /home/pi, but I wanted to install to /home/production so that everyone could use it. Here are problems that I encountered:

1. I put '/' at the end of directory names in RUSTUP_HOME and CARGO_HOME. This was reasonable. You folks didn't check for it.
2. The install died because etc library wasn't found. You folks should create it if not found.
3. After failing, I tried to "rustup self uninstall", and it said the package wasn't installed to ~/.cargo. Of course not!
4. You should not assume that if someone is uninstalling, that all directories and files are right where you put them.
5. If allowing library to be installed elsewhere, the updates to .bashrc and .profile should be allowed to be global.
6. The compiler kept giving "illegal instruction". --Probably because of installing to unfamiliar territory.

[jonas-schievink]

Please file rustup issues at https://github.com/rust-lang/rustup and ask questions about the installation process at https://users.rust-lang.org/

[rbtcollins]

I'm struggling a little interpreting this bug report, so if I have misunderstood anything, please be tolerant and correct me gently.

You say your name is /home/pi - do you mean your username is "/home/pi" or is your username "pi" ?

Re (1) what happened? Was some error reported? Did you have to remove the / ?

Re (2) what is an "etc library" ?

(3) - if CARGO_HOME is not set when rustup runs, it is assumed to be ~/.cargo_home. I would say this is documented at https://rust-lang.github.io/rustup/environment-variables.html but that particular variable isn't - we'll add that. RUSTUP_HOME which behaves the same way is. If you want to run with rustup in a different directory than the default you need to arrange for these variables to be set: there is no means for rustup to figure out that you want rustup to store its data somewhere else otherwise. We do have a global settings file, but it can currently only define a global default toolchain, as we don't yet have an official story for supporting single-global-installs and other related use cases.

(4): we should check that rustup is able to uninstall even when some paths are missing from the file system, as an install might have only partially completed. It may be that the message you saw was a warning not an error, and as you haven't included the message you saw, we'll have to reconstruct things - but either way, this is clearly a supported use case. However we won't make any attempt to find directories that have been moved: if a user moves a directory, it is up to them to inform rustup of that fact if they want rustup to remove the directory during uninstall.

5. This is one of the reasons we don't have a facility for performing global installs: .bashrc and .profile aren't global files to update globally. Perhaps some sensible design can be created, and if you want to help create one that would be great, but we don't have one yet.

(6) This is almost certainly a bug and not related to where things where installed. Creating a separate bug that only talks about that issue, with as much information as possible would be helpful for the rustc team I think. Something like this bug report. rust-lang/rust#14441

[workingjubilee]

5. If allowing library to be installed elsewhere, the updates to .bashrc and .profile should be allowed to be global.

The "global" locations you might be thinking of are /etc/profile and /etc/bashrc. These are not "dotfiles", and so they are not under Rustup's purview, as they often require an elevated privilege level to edit that Rustup does not assume it is running under. Indeed, this is essentially an anti-goal of Rustup's current design: there are checks to prevent unintentional sudo installations.

[workingjubilee]

@rustbot label: +O-linux