Rustup 1.5.0 released

[brson]

rustup 1.5.0 is out. rustup is the primary official method of installing Rust. To upgrade run rustup self update.

The main new feature in this release is the addition of the ‘rust-toolchain’ file. This is long-requested feature that allows one to check their toolchain override into source control. Below is the description from the README.

The toolchain file

rustup directory overrides are a local configuration, stored in
$RUSTUP_HOME. Some projects though find themselves ‘pinned’ to a
specific release of Rust and want this information reflected in their
source repository. This is most often the case for nightly-only
software that pins to a revision from the release archives.

In these cases the toolchain can be named in the project’s directory
in a file called rust-toolchain, the content of which is the name of
a single rustup toolchain, and which is suitable to check in to
source control.

The toolchains named in this file have a more restricted form than
rustup toolchains generally, and may only contain the names of the
three release channels, ‘stable’, ‘beta’, ‘nightly’, Rust version
numbers, like ‘1.0.0’, and optionally an archive date, like
’nightly-2017-01-01’. They may not name custom toolchains, nor
host-specific toolchains.

Other changes this release

This release also adds further installation logic to attempt to set up PATH correctly in more situations. Now if ~/.bash_profile exists it will be configured to put ~/.cargo/bin on the PATH. Eventually we’ll get to a point where PATH is always configured correctly - keep those fixes coming!

It also contains a fix so that rustup no longer fails on manifests with ‘unavailable’ packages. Unavailable packages are those that the nightly build system failed to produce for whatever reason. Several nightlies in the last few months have contained unavailable toolchains, and each time it was a crises because rustup handled them incorrectly. No more!

Thanks to everybody who contributed!

1.5.0

• Rename references to multirust to rustup where applicable
• Update platform support in README
• Allow rustup to handle unavailable packages
• Update libz-sys and curl-sys
• Teach rustup to override the toolchain from a version file
• Update sha2 crate
• Check for unexpected cargo/rustc before install
• Update PATH in .bash_profile

Contributors: Allen Welkie, bors, Brian Anderson, Diggory Blake, Erick
Tryzelaar, Ricardo Martins, Артём Павлов [Artyom Pavlov]

[Enet4]

The rust-toolchain file really is a nice feature, it sure felt missing in one of my nightly-only projects. But I just tried it out and I couldn’t find a built-in way to make Rustup install the toolchain requested by the project. Should we just do something like rustup toolchain install $(cat rust-toolchain), or is there a portable alternative?

I’ve also noticed that Rustup will refuse to use a nightly toolchain when a specific nightly version is specified, even if both versions match at the moment of running cargo. If I have a “rust-toolchain” file with nightly-2017-06-25:

$ rustup toolchain install nightly
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.20.0-nightly (fc9ccfdbe 2017-06-25)

$ cargo run --release
error: override toolchain 'nightly-2017-06-25' is not installed
info: caused by: the toolchain file at '«...»/rust-toolchain' specifies an uninstalled toolchain

Is it reasonable for Rustup to track these situations in future versions?

[Nemo157]

Personally I’m fine with nightly != nightly-2017-06-25, it’s the same that 1.18.0 != stable even if your stable is currently at 1.18.0. I assume it would be possible to extend rustup to know this in the future, but I don’t think it’s really worth it (only positive I can think of is a little bit of deduplication). If you’re working with projects that use nightly you should probably have been using overrides with dated nightlies already anyway since whatever nightly feature you’re using could suddenly change on you at any point.

[brson]

@Enet4 At present, yes, a user is expected to install the toolchain themselves; there are no situations where rustup will install a toolchain lazily as you might expect. Hopefully rustup gives an error message saying the name of the toolchain, so a user can know which one to install.

It’s also a longstanding limitation that rustup can’t correlate the main distribution channels to the archives.