rustup 1.4.0 is out. To upgrade run rustup self update.

rustup is the primary official method of installing Rust.

This is a pretty sweet release with some new features and nice fixes.

The big addition here is support for xz compression. Rust has
historically been distributed as gzipped tarballs, and so haven't been
compressed as much as might be desired, especially by those on slower
connections. Starting with Rust 1.19, which is available on the beta
channel today, Rust is also distributed with xz compression, which
this version of rustup will use by default. Here's a representative
sample of the difference in download sizes:

| file                                           | size    |
|------------------------------------------------|---------|
| rustc-beta-x86_64-unknown-linux-gnu.tar.gz     | 47.8 MB |
| rustc-beta-x86_64-unknown-linux-gnu.tar.xz     | 37.6 MB |
| rust-std-beta-x86_64-unknown-linux-gnu.tar.gz  | 78.6 MB |
| rust-std-beta-x86_64-unknown-linux-gnu.tar.xz  | 55.8 MB |
| rust-docs-beta-x86_64-unknown-linux-gnu.tar.gz | 12.5 MB |
| rust-docs-beta-x86_64-unknown-linux-gnu.tar.xz |  3.5 MB |
| rust-src-beta.tar.gz                           |  3.1 MB |
| rust-src-beta.tar.xz                           |  2.1 MB |

rustup will use the xz binaries silently, but you can verify that you
are actually getting the smaller downloads by running with -v:

rustup -v update beta

Implementing this required patches to several projects involved in
Rust distribution. Thanks @ranma42 for making it happen!

This version correctly detects Visual Studio 2017 installations during
installation, as does the upcoming Rust 1.19 release. Since Rust will
not correctly support VS 2017 until the next release, as a slightly
awkward consequence in the meantime rustup will happily install the
stable toolchain alongside VS 2017, but the toolchain will not
actually work without explicitly configuring the environment.

This release includes builds for x86_64-linux-android, finally
bringing the full Rust experience to x86_64 Android. Thanks @malbarbo
for his long toiling to realize this platform support.

And there's also a bunch of bug fixes. Thanks everybody for all the
help!

1.4.0

• set_file_perms: if the file is already executable, keep it executable
• Disable man support on Windows
• VS 2017 updates
• Show version of rust being installed
• Detect MSVC 2017
• Use same precision as rustc for commit sha
• Fix prompt asking for msvc even though -y is provided
• README: fix rust build dir
• Add support for XZ-compressed packages
• Add PATH in post-install message when not modifying PATH
• Cleanup download-related code in the rustup_dist crate
• Increase Rust detection timeout to 3 seconds
• Supress confusing NotADirectory error and show override missing
• Don't try to update archive toolchains
• Exit successfully on "update not yet available"
• Add a message when removing a component
• Use ShellExecute rather than start.exe to open docs on windows
• Clarify that rustup update updates rustup itself
• Ensure that intermediate directories exist when unpacking an entry
• Add the rust lib dir (containing std-.dll) to the path on windows
• Add x86_64-linux-android target
• Fix for help.rs suggestion
• Ignore remove_override_nonexistent on windows
• Update proxy setting docs
• Add sensible-browser to the browser list
• Added help for rustup toolchain link

Contributors: Andrea Canciani, bors, Brian Anderson, CrazyMerlyn, Diggory Blake,
Fabio B, James Elford, Jim McGrath, johnthagen, Josh Lee, Kim Christensen, Marco
A L Barbosa, Mateusz Mikula, Matthew, Matt Ickstadt, Mikhail Modin, Patrick
Deuster, pxdeu, Ralf Jung, Raphaël Huchet, Robert Vally, theindigamer, Tommy Ip,
Xidorn Quan

Have you thought about using the combined package?

| rust-beta-x86_64-unknown-linux-gnu.tar.gz | 149.96 MiB
| rust-beta-x86_64-unknown-linux-gnu.tar.xz |  67.18 MiB

The combined xz package is smaller than the individual packages combined, mostly because the compression takes good advantage of the manual file ordering we put in. The rustc and rust-std packages contain identical shared libraries in different paths (lib/ and lib/rustlib/$target/lib).

That's a good observation. I have not considered doing so before. It would require adding some new metadata to the manifest to described the combined package.

Here's an issue for it: Optimize downloads with the combined package · Issue #1160 · rust-lang/rustup · GitHub

There was a pr to enable host builders for aarch64, but it was closed. I opened an issue asking to enable some android host builders. The problem is that we are running at the limit of our travis capacity.

Meanwhile, one can build rustc and cargo using the disabled builders. For example, executing the command src/ci/docker/run.sh dist-armv7-android will generate some tarballs in obj/build/dist. The tarball named rust-* contains a combined installer that can be copied to an android device and used to install rust and cargo.

On the topic or archive size.
If you are willing to wait more for the compression, Brotli has the best compression ratio/decompression speed ratio(aka: download + decompression = best).
Dropbox has written a decompressor for Rust, which could be used if you are interested: https://github.com/dropbox/rust-brotli-decompressor .

For the "best ratio" claim, here is one of the benchmarks that expresses better exactly this benchmark(there are other benchmarks from the Brotli github but this shows better exactly the case rustup is interested here):
https://quixdb.github.io/squash-benchmark/
Example I used:

• Dataset: mozilla( Tarred executables of Mozilla 1.0 (Tru64 UNIX edition) ) - binaries, so about the same input.
• Machine: e-desktop(Intel® Core™ i3-2105) - seems like a typical user with a relatively weak hardware.
• Transfer + Processing:

• Transfer Speed Preset(old wireless standard) 802.11G(note: as speed increases, Brotli gains an advantage, because of the decompression speed)
• Sort by Total time
• Direction Decompression

Note that the shorter bar means a shorter period of time in total when Transferring + Decompressing.

xz -9:

• Compression Ratio: 3.83
• Decompression Speed: 43.07 MB/s

brotli -11:

• Compression Ratio: 3.54
• Decompression Speed: 184.22 MB/s

Compression Speed on peltast(Intel® Xeon® Processor E3-1225 v3):
xz -9: 2.29 MB/s
brotli -11: 361.11 KB/s

Could you try again with the rust distribution files as dataset? Previous experiments indicated that brotli was inferior: https://github.com/rust-lang/rust/issues/21724#issuecomment-289048874
If you used a configuration different from the default one, that would be useful as well.

EDIT: sorry, that did not take decompression speed into account

pass a hat around

Does rust fall under the Travis "open source project we wouldn't dream of charging money" umbrella, or is there space here for setting up a Patreon¹? Everyone who wants nightly on android² can chip in $5/mo, however many extra runners this buys each month are active that month.

¹Insert or write continuous crowdfunding platform of choice
²Or iOS, or mips, or whatever other tier 2/3 platforms there's demand for.

I am very interested in setting up some kind of paid platform support structure, and have long viewed it as something of an imperative, but we have not gotten organized about it yet.

With the number of platforms waiting to get official build support it's a fairly pressing issue. cc @alexcrichton @aturon

Possibly low hanging fruit:

• set up a button for arbitrary github users to run the android builds on a throwaway VM
• extend VM functionality to run through recent PRs while it's at it
• consolidate results in some non-authoritative secondary build tracker
• throw together a UI for vm admin to throw a BTC address into the build output, under the promise that coin collected thus is forwarded directly to the continued existence of the vm
• if this actually starts taking a significant amount of money, run self-hosted travis on EC2 spot instances or sth, with a central donation button