Beta testing

Hi all.

I’d like to introduce rustup, the fabulous new way to install and manage Rust toolchains. This is the successor to multirust, and began as multirust-rs by @Diggsey. Although there’s a lot of work yet to do on it, it is feature complete and I’d like to get some feedback. To try it just go to and follow the instructions - everything you need to know should be reachable from there. I strongly recommend uninstalling any existing version of Rust before doing so.

After you’re done come back here and consider the questions below and leave your feedback. This is an early beta, and there’s still a lot of churn to come over the next month, so I caution against recommending it for wider use yet.

Thanks to @Diggsey for creating multirust-rs, to @chriskrycho for reviewing the rustup CLI, @alexcrichton for setting up the build infrastructure, and to all the multirust and multirust-rs users and contributors.

Does grouping commands into subcommands help?

In order to make the CLI interface more approachable and leave more room for expansion I’ve grouped commands together logically, so commands that just manage toolchains are under rustup toolchain [subcommand], those that deal with overrides rustup override [subcommand]. While this makes the CLI in some ways feel more consistent it also makes some common commands more verbose: for example adding a target is now rustup target add instead of rustup add-target. To then combat this verbosity there are some top-level commands that can be thought of as shortcuts, most notably the rustup update command, which could also be thought of as rustup toolchain update (which isn’t implemented to to avoid duplication).

The three ‘sub-command’ commands, toolchain, override and self also notably don’t do anything intersting when not provided a subcommand. In other words, whereas rustup toolchain list is a real command, rustup toolchain, the shorter command, doesn’t do anything. I could imagine rustup toolchain for example displaying the current toolchain like rbenv version (but I have other reservations about using rustup toolchain for this).

I still feel mostly good about this direction, but not sure if the ergonomics are in order yet.

Do rustup and rustup update do the right thing?

The simple rustup command is the ‘update all the things’ command. It updates all toolchains and self-updates, without confirmation. Originally I wanted this to be the only update command, but pretty quickly found myself just wanting to update nightly, so added rustup update. Now there are three ways to update toolchains: rustup, rustup update nightly, which does what you expect, and rustup update which updates the active toolchain.

I’ve already found myself typing rustup update and mistakenly wondering why it wasn’t ‘updating all the things’, which makes me think there are too many ways to update.

Are the verbs right?

A lot of the rustup commands are transactional: add or remove some piece of the system. For example

  • rustup update <toolchain> / rustup toolchain remove <toolchain>
  • rustup target add <target> / rustup target remove <target>
  • rustup override add <toolchain> / rustup override remove

So the ‘add’ / ‘remove’ verbs are consistent except for with toolchains, which use ‘update’, not ‘add’. And again, update being its own command for convenience makes the lack of a rustup toolchain add command inconsistent.

I happen to prefer three different verbs for adding here - ‘update’ for adding (or updating) toolchains, ‘add’ for adding targets to an existing toolchain, and ‘set’ for setting the override. If we were to follow that though then it would provide no intuition at all for adding different types of things.

What information is missing from the website?

The website is supposed to be very slim, just enough to convince you to run the installer and get you on your way. Is there any other information that you were expecting to be given during install?

If anybody wants to try their hand at the website style too, I’m not wedded to this. I generally am going for something simple, strong, and authoritative. People who encounter it should think, “yeah, this website knows what’s up; I’m going to do what it says”.


I uninstalled multirust, ran the installer, sourced the script, and then:

$ rustc --version
error: multirust's metadata is out of date. run multirust upgrade-data.


$ rustup self upgrade-data
info: upgrading metadata version from '2' to '12'
warning: this upgrade will remove all existing toolchains. you will need to reinstall them

seems to have fixed this. Still not clear why it’s talking about multirust here.

Okay, last post, I swear: I was also then confused when the stable toolchain wasn’t installed like it used to be. Dunno if this is good or bad. :smile:

After installing rustup-setup.exe on Windows 7 (64bit) I got the “This program might not have installed correctly” warning dialog, but other than that everything works fine so far.

Ok steps I took were

curl -sf | sh -s -- --uninstall (uninstall multirust)

curl -sSf | sh

source $HOME/.cargo/env

multirust upgrade-data (strange step name)

rustup install stable

Then I wanted my cargo commands back so

cargo install rustfmt


All seems running well now. Nice work, initial test looks good. Should help the community a lot to stabilise and get all verbage right etc. Now to play with cross compile etc. :wink:


I’m utterly confused by this. So apparently rustup install nightly is a thing, yet rustup --help shows no commands?

Also the curl installation method puts a bunch of stuff into ~/.cargo yet rustup install nightly puts it into /usr/local?!

Okay. rustup install is not a thing. To install one uses rustup update nightly now.

Just tried this on Windows 8.1

First of all, “Windows SmartScreen prevented an unrecognized app from running. Running this app might put your PC at risk. Publisher: Unknown Publisher”.

After the confirmation Y of Continue? (Y/n) the console window closes very quickly. I noticed some panic message before the window closed, but it disappears too quickly to be read. HKEY_CURRENT_USER/Environment/PATH is not updated, some binaries however appear in %USERNAME%\.cargo.

Thanks for your work on this!

I agree with grouping the commands hierarchically (“override add” instead of “add-override”). That was one of my main annoyances with multirust previously. Subcommands which are only used for grouping their subcommands should use Clap’s AppSettings::SubcommandRequiredElseHelp setting to automatically explain what they contain to the user when not presented with a subcommand. I don’t think such “group only” subcommands should have any behavior themselves.

As for the website:

  • should 301 redirect to with the HSTS header.
  • The design should match the main Rust website to make it more clear that it’s an official way to install Rust. Right now there’s no way to know if this is just someone’s pet project or if it’s official.
  • Perhaps the site should be hosted at or something to make the official distinction very clear.
1 Like


I tried this out locally. Due to being on fish, it didn’t update my $PATH automatically, and said:

It will add the `cargo`, `rustc`, `rustup` and other commands to
Cargo's bin directory, located at:


This path needs to be added to your `PATH` environment variable ...

which I dutifully did. But it seems the actual dir needed is ~/.cargo/bin (missing the /bin above).

1 Like

So I ignored your instructions to uninstall Rust first, and got:

~ $ rustup
error: multirust's metadata is out of date. run multirust upgrade-data.
~ $ multirust upgrade-data
multirust: upgrading metadata from version 2 to 2
multirust: metadata is updated to version 2
multirust: success
~ $ rustup
error: multirust's metadata is out of date. run multirust upgrade-data.

I’m on OSX FWIW.

I’m getting

$ curl -sSf | sh
usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
       mktemp [-d] [-q] [-u] -t prefix
rustup: command failed: mktemp -d
info: downloading installer
mkdir: : No such file or directory
rustup: command failed: mkdir -p

on OSX 10.10 after uninstalling multirust with

$ curl -sf | sh -s -- --uninstall.

How can I pick a different target directory (instead of ~/.cargo), and have rustup not mess with my shell config file (I’ll add to $PATH myself)? With my only options seem to be “Continue? (Y/n)”.

The former is controlled by the CARGO_HOME environment variable. For the latter I’ve built from source with a change, but a command-line option or environment variable to do this would be nice.


Thanks for testing. There are several things conspiring to make the multirust->rustup upgrade not work very well right now, but at least you got through it! That's better than I feared.

One thing to be aware of is that rustup is still using ~/.multirust for its data. It'll move to ~./rustup soon.

I think I'm going to add an installation step that probes the system for a variety of 'old' configurations and tries to resolve them before installation.

@zsiciarz Do you know what this means? I hope this isn't some weird side-effect of the application containing the word setup in the name...

@dirvine Yeah, this is just an error message that needs to change.

@mitsuhiko No rustup install is not a command. Where did you get that impression?

rustup should not be touching /usr/local. rustup install nightly should install to ~/.multirust/toolchains/nightly (the directory hasn't been renamed yet).

Thanks for the report. This is all bad! Issue.

I'm not sure if there's something simple we can be doing to lessen the UAC, etc. warnings on Windows.

@jimmycuadra Huh, I thought I set up the redirect, but it's definitely not doing it. Issue.

Yeah, I've been conflicted about how official to make this. When I started on it I wanted it to be clearly unofficial for a while, but the project is on the fast-track to being on official project.

I know that whether this is official is one of the questions people are going to have when asked to install something, so it should be conveyed.

As to giving the website the same style as the Rust website, I'm conflicted. I really did want to take the opportunity to do something new - I've been maintaining that same style on the Rust website for years.

At some point the main website will be redesigned to incorporate rustup, and that will hopefully obsolete the rustup website.

As to hosting at, the main reason I didn't do that is to give rustup space to grow as an unofficial project before it has to deal with the commitments of being the rust installer. It also enables the cute and domains.

Anyway, I'm open to dropping the rustup domain.

Good catch! Issue.

I suspect this happened because the multirust you ran was actually the old multirust shell script, which happily did a no-op upgrade.

I'll put more defensive measures into the upgrade to prevent these things.

@euclio Damn. When I was writing this script I had a nagging recollection that it's hard to use mktemp compatibly. Should be an easy fix. Issue.

Right now I don't intend to allow installation to non-cargo directories - part of the intent with the design is to double-down on ~/.cargo/bin as the place for all rust binaries. We really want to steer people to have it in their PATH. You can though set CARGO_HOME to tell rustup-setup where this directory is.

Disabling PATH modification is not implemented yet. Issue.

1 Like

Thanks for the testing so far everyone! It’s been really helpful. I’ll do my best to resolve the issues you’ve seen this week.


FWIW, I also kind of assumed there’d be an install command. Typing “update” to install a thing feels a bit strange, but my brain glossed over it.

1 Like

I just installed the latest rustup/multirust on my Windows 7 machine. It’s working so far. What’s interesting though is that now all rustup-related files are stored in C:\Users\<username>\.cargo and C:\Users\<username>\.multirust while completely ignoring old files from C:\Users\<username>\AppData\Local\.multirust. Related to that, is it on purpose that files are stored in the home folder instead of AppData\Local?