Beta testing

rustup 0.3 is out. Notable this release is a new fix for installing pre-1.8 releases, the beginnings of support for rustls, a mostly-Rust TLS library, a new hack to make the annoying checksum failures sound less dire.


Contributors: Alex Crichton, Brian Anderson, Drew Fisher, geemili, Ivan Petkov, James Lucas, jethrogb, Kevin Yap, leonardo.yvens, Michael DeWitt, Nate Mara, Virgile Andreani


What’s the best way to upgrade an existing install?

1 Like

Generally, rustup self update should do the trick @wezm.


rustup 0.4.0 is out. To get it run rustup self update.

This release brings the hyper backend’s proxy support up to parity with the curl backend and documents how to use HTTP proxies. It also adds a compile-time ‘no-self-updates’ feature for use by those distributing rustup through other package managers.


Contributors: Alex Crichton, Brian Anderson, Ivan Nejgebauer, Jimmy Cuadra, Martin Pool, Wesley Moore


Arch package has been updated, including now using the no-self-update feature :slight_smile:


rustup 0.5.0 is out. To get it run rustup self update.

This release features a more convenient syntax for executing tools from an arbitrary toolchain. Instead of e.g. rustup run nightly rustc, you can now run simply rustc +nightly That is, execute the toolchain command directly, and if the first argument begins with + it identifies a toolchain name and uses it. Neat idea from @DanielKeep. Let me know what you think of it.

It also adds the rustup man command, which simply displays a man page for the active toolchain, contributed by @theindigamer; and continued work by @inejge on creating an HTTP backend using the rustls Rust TLS library.

Finally, this contains mitigations against misconfiguring the rustup install by running it under sudo. If it detects that it is about to write root-owned files to a non-root home dir it will complain. This type of systems-integration code can sometimes cause surprises, so I’m interested in wider testing. If you are running a less-used Unix you might try to run the installer again (no need to uninstall first) and see if it does anything unexpected.

Thanks to everybody who contributed, and thanks to everybody for testing, reporting issues and running rustup!


Contributors: Brian Anderson, Cam Swords, Daniel Keep, Diggory Blake, Florian Gilcher, Ivan Nejgebauer, theindigamer


Hey there.

There’s a bug in the interaction between the currently-deployed rustup and the latest nightlies that you may run into. It doesn’t look like I’ll have a fix out tonight, so I’m giving you a heads up.

The symptoms are that rustup show and rustup target list will panic when they try to print information about the nightly toolchain. As far as I know things will otherwise continue to work.

What’s happened is that we’ve updated the distribution manifest format to include packages of the Rust source code, and the current version of rustup handles this incorrectly in some cases. Since the breakage only seems to affect commands that report toolchain status and not the installation/operation of the toolchain, I intend to press forward, fix the bug in rustup and urge everyone to upgrade.

@Diggsey has already landed a fix (thanks so much!), but since it’s late today I’m not sure if I’ll get it deployed tonight. It could be as late as Monday that I get a fix out.

I apologize for the disruption.


rustup 0.6.0 is out. Update with rustup self update.

As mentioned previously, this fixes a serious bug with manifest handling, wherein rustup show and rustup target list panicked on recent nightlies.

This adds a new rustup component subcommand which is a generalized version of the existing rustup target subcommand. This one though allows installation of any ‘component’ package, a component being the unit of installation in rustup. The cool thing this is going to allow you to do is install the Rust source code, via rustup component add rust-src. Unfortunately, due to bugs in the generation of the rust-src package, it doesn’t work quite yet, and if you try today rustup will report a ‘corrupt manifest’ error. Once the upstream fix is merged though nightlies should begin coming with optional source components.

The installed source is in the lib/rustlib/src directory of the sysroot, and the sysroot can be discovered with rustc --print sysroot. The precise layout of this directory is not specified. Tools are expected to find the source of crates they need by walking the directory and reading Cargo.toml files. As an optimization they can use implicit knowledge of the structure of the rustc source tree to find the right Cargo.tomls quickly, but to be resilient they need to fall back to walking the tree.

Thanks @Diggsey for putting all the pieces together to make the rust-src package happen.

The other new feature in this release is the addition of the --path and --nonexistent options to rustup override unset, which allows overrides to be removed for paths that no longer exist.

Finally, @Boddlnagg has been doing amazing work integrating rustup into a Windows MSI installer. It’s not ready to test yet, but has been making quick progress.


Contributors: Alex Crichton, Brian Anderson, Diggory Blake, Ivan Nejgebauer Josh Machol, Julien Blanchard, Patrick Reisert, Ri, Tim Neumann


@alexcrichton already found a bug in rustup component remove. Fortunately it doesn’t matter much since you can’t install rust-src yet anyway. I’ll try to get some fixes in tomorrow before working rust-src packages are deployed.

rustup 0.6.1 is out. Update with rustup self update.

This fixes a segfault during installation on OS X 10.10+, and makes the rustup component remove command work correctly.

Fixed rust-src packages are still not available on nightly. It looks to me like they should be available Thursday, though there is still more testing to do to verify things work.


Contributors: Brian Anderson, Diggory Blake


Is there a way to make rustup not download the rust-docs component?

@gkoz Not yet, but it’s something I would like to do. Haven’t filed an issue on it (it’s continually on my todo to sort out the rustup roadmap and file tasks for people to help with). Today the toolchain manifests divide components into ‘required’ and ‘optional’, where optional are not installed by default. If we want rust-docs to continue to be installed by default (it’s not obvious to me, but since that’s the status quo seems a reasonable stance), we’ll need to update the manifest format backwards compatibly to indicate components that are installed by default but optional (probably add a ‘required = true’ key); then teach rustup-init to do component selection.

@brson We’re considering adopting rustup as an official package in Arch Linux, however we’re running into some issue regarding interoperability with packages that require stable. Could you chime in to the discussion at (see comments starting from Svenstaro’s post at 2016-08-25 14:11), or give some thoughts here that I can relay?


@jonhoo I left some comments on the arch thread. Feel free to ping me here if I fall behind checking up on the responses there.

Since non-Arch users may have ideas about the solutions to packaging rustup in distros I’m producing my post there here as well.

Hi. I’d like for rustup to work cleanly when packaged by distros, but haven’t put much effort or thought into it. There are a variety of concerns expressed here and I’m not familiar with the details of arch’s rustup packaging, so let me just brain-dump, and feel free to correct me and respond liberally.

Issues with rustup distro packaging

  • Where does rustup get installed to? Stock rustup wants everything in ~/.cargo/bin, including the rustup bin and its proxies. Distros may be inclined to put them in /usr/bin, and this is probably the correct thing to do from their perspective. I don’t see an obvious reason that wouldn’t work for rustup, but not so for rustc/cargo…

  • If rustup proxies are installed to /usr/bin how can they co-exist with distro-installed rustc/cargo? Both bins want to be installed there.

  • Even if the rustup proxies and the rustc/cargo bins can coexist on disk, how can somebody live in the rustp world while still using the system-installed toolchain? I think it makes sense to reserve a “system” toolchain name in rustup for this purpose but haven’t thought it through.

  • rustup self-updates are incompatible with distro packaging. For this we already have the “no-self-update” feature. Is there any more to be considered here?

  • rustup-init installs some toolchain by default. It is generally desirable to be able to install rustup without installing a toolchain. Having “system” be a valid toolchain would be one way around this limitation, in lieu of having a way to say “don’t install a toolchain”. It looks to me like this is not an issue for distros since their packaging just drops rustup and its proxies directly where it wants without running the rustup installer (basic rustup install is purposely simple like this).

  • Interaction between packaged Rust software that expects particular versions of rustc and rustup is bad. If Rust software wants to depend on rustc 1.10 it can do this traditionally via the package manager, but there is no way to express this if rustup is controlling the rustc version. Tricky issue.

  • The above case is most obviously manifested when building packages from source written in Rust. These expect to be built by the system’s toolchain. There may be ways to signal to rustup that these compilation scenarios should automatically use the “system” toolchain. e.g. if the source of these packages is always built in a specific subtree, there could be an override set on that subtree that tells rustup to use the "system" toolchain. Some complications here in the current design since you can’t just drop a configuration file into the tree itself to configure that like with rbenv.

  • rustup doesn’t have an option to install toolchains globally. Desirable feature, but needs careful design, haven’t put much effort into it.


To the suggestion of installing the rustup proxies as /usr/bin/{cargo,rustc}-rustup. This poses several difficulties, that I’m inclined not to do it. First, usability-wise it means that rustup users need to know to type cargo-rustup when working in Rust. This is pretty counter to rustup being a transparent drop-in for cargo; and I expect that if you install rustup it’s because you want to be in a rustup-world. Second, tools (primarily cargo) expect to be able to invoke rustc, etc. as ‘rustc’, and in rustup-world that rustc should be the rustc proxy. There are potential solutions to this, but I’d rather avoid.

There are some problems where it’s tempting for rustup and the system package manager to communicate about the active toolchain. I’d like to avoid this if at all possible. Very complex.

The idea to install rustup without its proxies is doable, but rustup would be quite crippled. It does break the primary functionality.

There will likely be situations in the future where rustup wants to create and delete proxy bins dynamically. This could change the calculus of the issues here in ways I’m not sure about yet, but istm the problems are not major - rustup will just create those proxies in ~/.cargo/bin as if it was doing cargo install.

I like the idea of a “system” toolchain where rustup can search the PATH for a copy of the tool it isn’t managing and defer to that, but the obvious problem is that both the rustup package and the rust package want their bins to be installed at the exact same place. I think if that issue is solved there is some path forward for solving the others.

Is it possible for the rustup package to modify the system-wide PATH variable? One solution would be to let the “normal” rust packages have the sweet /usr/bin location on the file system, and just put rustup somewhere else, with PATH precedence. Then let rustup defer to the system rustc via the rustup "system" toolchain, have rustup modify the override for the system package build directory to use the “system” toolchain during its install.

Just a quick idea. What if you had the following, when installing both rustup and rust-X.Y (system rust) in parallel?

/usr/bin/rustup - rustup binary
/usr/bin/rustc - rustup rustc proxy
/usr/bin/rustc-X.Y - system rustc
/usr/bin/cargo - rustup cargo proxy
/usr/bin/cargo-X.Y - system cargo

In this case, you could have rustup use the system binaries as the defaults if they are installed and if they aren’t, you could default to an install with no toolchains. If you do that, you can install all the other toolchains in user home directories. I think this would only require a rustup config file in /etc/ to specify the system toolchain, when installed and it would be optional and rustup would never write one.

Edit: I’m mostly familiar with debian and it’s alternatives mechanism, which would allow something like this to work (though I’m not sure how they resolve alternative priorities):

/usr/bin/rustup - rustup binary
/usr/bin/rustc - symlink managed by distro alternatives
/usr/bin/rustc-rustup - rustup rustc proxy
/usr/bin/rustc-X.Y - system rustc
/usr/bin/cargo - symlink managed by distro alternatives
/usr/bin/cargo-rustup - rustup cargo proxy
/usr/bin/cargo-X.Y - system cargo

This would potentially allow you to get symlinks from rustc -> rustc-X.Y without rustup installed and then install rustup and have the symlinks change to rustc -> rustc-rustup, and rustc-rustup would default to calling rustc-X.Y, but would allow toolchain overriding, etc. like normal.


The idea to install rustup without its proxies is doable, but rustup would be quite crippled. It does break the primary functionality.

Installing rustup without its proxies is the mode that would work the best for me. Here’s my thinking, partly repeating what’s in that AUR package thread. Curious whether anyone else’s thinking is similar:

  • Like @brson mentioned above, it substantially simplifies the story around Linux packaging, where rustc and cargo are already installed as independent packages. Some package written in Rust might want to take a build dependency on rustup, to compile with nightly for example, but that’s a drag if the rustup package conflicts with the rustc package.
  • I’m not a big fan of global state in my build tools. Instead of remembering what default toolchain mode I’m in right now, I like to define separate aliases that always refer to a specific version. Something like
alias rustcn="rustup run nightly rustc"
alias cargon="rustup run nightly cargo"
  • Changing what’s in the PATH can have a lot of unintended side effects, if you’re on a system that builds things from source. That includes AUR packages on Arch, for example, but also Vim plugins like YouCompleteMe that have a native Rust component. Usually you’re building those things to use them, not to hack on them, and it’s confusing if your rustup config breaks those builds. (Running rustup default 1.0.0 would probably break everything.)

Of course all of this is totally different on Windows where Rustup is the official way to install the whole toolchain. Can anyone talk about the situation with Homebrew on OSX?

@ahmedcharles Either of those schemes is workable in rustup, as long as they are in the distros. Assuming a distro that doesn’t have Debian’s alternatives mechanism, it seems like it could be problematic for distros since they wouldn’t want all their rustc’s to be called rustc-X.Y when rustup is not installed.

@oconnor663 Thanks for the details!

RedHat family distros also have an alternatives mechanism similar to Debian’s. It’s a bit unavoidable when you want to package VIm and elVIs, or Sun Java and OpenJDK.

If you don’t have alternatives, a distro can package rustc-X.Y with versioned names and have a rustc package that conflicts with the rustup package and the rustc package provides symlinks. I believe that’s a fairly standard way of packaging compilers?

Though, I agree with @notriddle, in that distros probably have a way to deal with alternatives/conflicts in a reasonable way at this point. If they don’t, rust (at least) won’t be alone in causing them grief.

1 Like