Specifying an installation directory

[AtheMathmo]

A quick search through the issue tracker came up short - my apologies if this has been asked before.

I'm wondering if there is a way to specify an installation directory other than e.g. $HOME/.cargo .

I'm faced with a situation right now where it would be useful. I'm using a custom buildpack to deploy a Rust app to Heroku. Heroku provides a Cache directory which persists between builds - but as I am unable to install to this directory I have to reinstall my toolchain and dependencies each time.

If this isn't currently possible and is deemed useful I'd be happy to take a crack at it.

[brson]

Hi @AtheMathmo!

Today rustup-init will obey both CARGO_HOME and RUSTUP_HOME to control .cargo and .multirust respectively.

This is not explicitly documented, but should be. Perhaps in the Installation section of the README.

It probably also make sense to add installation options to the installer, both interactive and non-interactive. What do you think @Diggsey @alexcrichton ?

[brson]

Hm, changing the installation dir in the installer comes with some complexity because after installation the environment should be configured with custom values for CARGO_HOME and RUSTUP_HOME or else it won't work right. Think we should hold off on that.

[alexcrichton]

Sounds good to me!

[AtheMathmo]

Thanks for the reply.

I managed to get this working locally with the following command

CARGO_HOME=$CACHE_DIR RUSTUP_HOME=$CACHE_DIR bash -c 'curl https://sh.rustup.rs -sSf | sh -s -- -y'

I had to use bash -c so that the variables would persist through the pipe. If you know a better way I'd be happy to hear it.

However this didn't work as expected. Though rustup is added to the path if I try to uninstall I see the following:

$ rustup self uninstall error: rustup is not installed at 'C:\Users\james.lucas\.cargo'

And if I try to use cargo:

$ cargo error: no default toolchain configured

I am using windows with MINGW64, which may be adding some complication. I'll try doing this on my ubuntu machine in a little while.

---

Edit: Managed to get past the uninstall error by setting CARGO_HOME/RUSTUP_HOME again. I then faced a permissions issue so I had to brute force it.

[AtheMathmo]

Similar issues on Ubuntu.

I install with:

RUSTUP_HOME=Test CARGO_HOME=Test bash -c 'curl https://sh.rustup.rs -sSf | sh -s -- -y'

Calling cargo: error: no default toolchain configured

Calling rustup self uninstall: error: rustup is not installed at '/home/james/.cargo'

Trying to uninstall with CARGO_HOME=Test RUSTUP_HOME=Test rustup self uninstall:

info: removing rustup home
info: removing cargo home
error: failure reading directory

The Test directory is deleted but ~/Test/bin is not removed from my path (in the active session).

The biggest issue here for me seems to be the toolchain problems. From what I understand there should always be a global toolchain set? I suppose for now I could just override the directory toolchain in the heroku build pack.

Let me know if I'm misunderstanding anything.

---

EDIT: Sorry for the information overload. I managed to fix the toolchain issue just by adding rustup default stable before trying to use cargo. I'm not sure why it doesn't get added by the script.

Looks like it is usable for what I need - albeit with a few quirks.

[brson]

Thanks for the further investigation @AtheMathmo. This does indeed look all kinds of buggy. I am not sure what's happening offhand but I will try to investigate ... sometime 😢

[AtheMathmo]

No problem. I'm happy to put a little more time in trying to figure this out. If you know the relevant areas of code I can dig around a little - though I'm not sure I'll be of too much use.

[ruuda]

Setting RUSTUP_HOME as documented in the readme does not work for me on Windows 7 x64. I tried both setting the environment variable in Windows, and explicitly running rustup-init.exe as RUSTUP_HOME=... /path/to/rustup-init.exe from a Git Bash shell.

My personal use case for this is that %USERPROFILE% is on a small SSD; I have a separate disk to install software on. Software putting things in %USERPROFILE% is filling up my SSD, and changing the location of the user profile is not possible after installation.

Version: rustup-init 0.6.4 (e6dc1c6 2016-10-24).

[retep998]

@ruuda I personally installed rustup.rs normally, and then set RUSTUP_HOME and CARGO_HOME and copied the rust/cargo/rustup stuff to those new directories. It's not as convenient as installing directly to the desired location, but it works.

[ruuda]

@retep998 great idea! Now that I check, it looks like Rustup put the toolchains in my configured RUSTUP_HOME after all, but it also created binaries in ~/.cargo/bin. The toolchain directory contains dlls but ~/.cargo/bin does not. During installation it told me it was going to install to C:\Users\Ruud\.cargo\bin, even though I had set RUSTUP_HOME to a different location.

[Diggsey]

@ruuda RUSTUP_HOME only controls the location of the toolchains, as you've discovered. CARGO_HOME controls the location of the binaries.

[aidanhs]

~/Desktop/rust/crater $ rm -rf work
~/Desktop/rust/crater $ ls work
ls: cannot access 'work': No such file or directory
~/Desktop/rust/crater $ CARGO_HOME=./work/local/cargo-home RUSTUP_HOME=./work/local/rustup-home /tmp/tmp.6u0ylcBbVc/rustup-init -y --no-modify-path
warning: it looks like you have existing rustup.sh metadata
warning: rustup cannot be installed while rustup.sh metadata exists
warning: delete `/home/aidanhs/.rustup` to remove rustup.sh
error: cannot install while rustup.sh is installed

Unfortunately, it seems like CARGO_HOME and RUSTUP_HOME are ignored when doing sanity checks, so you can't install rustup to a custom directory alongside an existing version in the default location.

Edit: my mistake - my rustup was old and had an old directory structure, upgrading fixed it

[gnzlbg]

Choosing where to install something is pretty basic functionality.

Hm, changing the installation dir in the installer comes with some complexity because after installation the environment should be configured with custom values for CARGO_HOME and RUSTUP_HOME or else it won't work right.

So just print a message telling the user to set those variables ? I mean, the installer already sets the PATH for the user, which is extremely fishy since chances are this will be lost on re-loggin. We should just be printing a message here telling the user that for everything to work correctly these variables must be set. Ideally, in an easy to copy-paste way.

That's pretty much what all installers do that install something that require setting the environment in any particular way. There is no reliably way for the installer to set these, so this is something that users just have to do or else nothing will work.

[codec-abc]

What is the status on this? At work, I have a very small C: disk and to avoid cluttering it and install all the Rust related thing somewhere into D:. After, launching the latest version of rust-up.exe the installer does not ask for a path even with a custom installation. How should I proceed to have a working Rust installation?

[Manishearth]

Moderator note

Please don't pile on on issues pressuring people to fix them. Rust is a volunteer-run project and sometimes things just take time. If you want to help it might be possible to ask the maintainers to provide pointers for what code specifically needs fixing.

Thanks!

(Please do not reply to this comment, if you have questions email rust-mods@rust-lang.org)

[kinnison]

For those interested, you can amend the place that rustup stores your toolchain. That is what the RUSTUP_HOME environment variable is for.

Documentation to this effect is in https://github.com/rust-lang/rustup.rs/#choosing-where-to-install

As such, I'm going to close this issue.

[gnzlbg]

@kinnison Does the installer already tell users that this can be done, and how to do it, or does the installer ask the user if they want to install rustup in a non-default location, and let them specify a path ?

An installer that does not do that gives a pretty bad impression, particularly if the user needs to install things first, then search for where the things got installed, then find out whether that installation path can be changed, then remove the installation, and then reinstall things again.

IMO the installer should be at least telling users where it is going to install things, and whether that can be changed, and how to change it.

Something like:

The Rust toolchain will be installed in {RUSTUP_HOME} and cargo will use {CARGO_HOME}.
Are these directories ok?

[Input:] Y/n

(on n): To install the Rust toolchain in a different directory, set the RUSTUP_HOME and/or CARGO_HOME environment variables to appropriate values before running the installer. (program exit).

[kinnison]

Currently we only report the CARGO_HOME information, not anything about RUSTUP_HOME so that part is only documented in the README.

I'm not sure quite what the best way to provide this is, but if you feel your example is sufficient then please open a fresh issue to request that directly.

[VitorEAFeliciano]

With your hints managed to get it working and successfully build projects like libredirectionio.

export CARGO_HOME=/opt/.cargo
export RUSTUP_HOME=/opt/.rust
export PATH=$PATH:/opt/.cargo/bin
add to /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin::/opt/.cargo/bin"
CARGO_HOME="/opt/.cargo"
RUSTUP_HOME="/opt/.rust"

curl https://sh.rustup.rs -sSf | sh

[rubyFeedback]

I just found the issue here. My use case is a bit different - I install everything into versioned
AppDirs on my linux system, in a special directory.

Rust would reside at e. g.

/home/Programs/Rust/1.33.0 # or whatever the version

That directory ( /home/Programs/ ) I also regularly back up, install onto other
computers etc...

GoboLinux uses a simpler scheme, with only /Programs/. I was also using
this until I realized that (a) the glibc variant also plays a role (evidently,
since the various .so files will tap into the libc on the system) but more
importantly (b) because I tend to use the whole /home/ target differently
from the rest of my system (I actually only back up into /home/; everywhere
else I let ruby autogenerate config files, so I really only have to ever
backup /home/ and nothing more).

I suppose I could find all files rust installs and use a script to relocate all
files into a versioned directory like the above, but if rust-up itself would
support this then it would eliminate a manual step for me.

(The issue here is quite long; I think it would be best if somewhere there
could be a toplevel comment or so, in a HOW TO SOLVE this issue
or something, so people can more easily find the answer. Right now as
I write this, I am not 100% sure about the answer - I will try with
RUSTUP_HOME first and hope that this will lead to the desired
installation prefix.)

A configure option such as --prefix or --installation-prefix or something
like this would be convenient, although the environment variable
works too. (I just hate environment variables in general - after you
end up with more than 3000 on your linux system after ~20 years,
with some side effects you can not anticipate, you may understand
why I consider environment variables very, very brittle and try my
best to avoid them).

Hmm tried it.

The target ended up being:

/home/Programs/Rust/1.44/toolchains/stable-x86_64-unknown-linux-gnu/

There are the bin/ lib/ etc... subdirectories.

I suppose the toolchains/ directory is hardcoded. If this is the case
then RUSTUP_HOME is actually not what I thought it is. I thought
it would refer to the BASE directory. It is not big deal - I just copied
this to: /home/Programs/Rust/1.44/ then did the regular symlinks
I use, and rust works fine. So it is only cosmetic. Perhaps not worth
to fix it, but I'd like to point out that RUSTUP_HOME appears to
not be entirely what we may expect from e. g. GNU configure
--prefix= since that specifies the whole base directory (root
directory) for the program at hand. I assume regular rust-up
installs into the home directory of the user somewhere, so perhaps
you guys don't want to add separate bin/ lib/ entries there, which
is understandable - but it is not the same as --prefix. Perhaps a
separate --prefix could be used, to specify the base dir? But as
said, my problem was solved, rust works, so no big deal.

[kinnison]

No, RUSTUP_HOME is where rustup manages its content, it is meant for nobody but rustup and its layout and content is not considered a stable ABI.

[daveloyall]

I read every comment on this issue and did some web searches. I have concluded that RUSTUP_HOME is not documented except here. I'm probably wrong, but I don't currently see how. So, I recommend documenting that!

[kinnison]

RUSTUP_HOME is documented in the book for example here: https://rust-lang.github.io/rustup/environment-variables.html

[pcdinh]

For Windows users

1. Download rustup‑init.exe from https://rustup.rs/ and move it to a directory you wish. E.x: C:\rust
2. Create a .bat file with the following content (change paths below to the ones you wish)

set CARGO_HOME=C:\rust\.cargo
set RUSTUP_HOME=C:\rust\.rust
set PATH=$PATH:"C:\rust\.cargo\bin" 
rustup-init.exe

3. Run the above .bat file

[Bauxitedev]

@pcdinh I don't think this is correct. I just tried it, but after installing it this way, any new process that opens still uses the wrong CARGO_HOME and RUSTUP_HOME, so it will still create a .rustup folder in your Users folder if you use cargo or rustup afterwards, which is not the intention.

You need to set these variables globally and permanently like this, then restart your PC. Then, install rustup the usual way. Then it works properly.