Beta testing rustup.rs


#138

There’s a new feature in 0.2 intended to improve the windows experience. The new default-host setting controls which platform rustup installs compilers for. So on Windows, where rustup installs the i686-pc-windows-gnu compiler by default, you can change the default host to e.g. x86_64-pc-windows-msvc and rustup will assume that you want the compiler for that platform unless explicitly told otherwise. This setting can be changed interactively during install or with rustup set default-host.

This feature doesn’t have docs published yet but here’s what I just wrote for the README.


#139

To update rustup, rustup self update.


#141

I was trying to add a homebrew recipe for rustup. So it would be great if the installation supports an option to avoid interactivity (automatically press 1) and a --prefix option to place the installation elsewhere. If I have some time I can try to implement something like that but no promises since I haven’t done any Rust yet so I will take more time than it should.


#142

I don’t know your exact requirements but rustup-init accepts a -y flag that makes installation non-interactive.

You also need to be concerned with rustup self-updates. Presumably if you are installing through homebrew you want homebrew to do the updates, not rustup. For this I’d like to be able to build rustup with a compile-time option to disable self-updates.

I’d like to know more about what you want out of the --prefix option. Part of rustup’s design is to install bins to ~/.cargo, making all Rust bins live in the Cargo world. What would be the effect of --prefix? Putting rustup in a different directory? Putting rustup and the command proxies (rustc, cargo, etc) in a different directory?


#143

The idea with --prefix would be to follow homebrew directory structure and install stuff in /usr/local/Cellar/rustup/0.2.0/


#144

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.

0.3.0

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


#145

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


#146

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


#147

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.

0.4.0

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


#148

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


#149

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 main.rs, you can now run simply rustc +nightly main.rs. 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!

0.5.0

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


#150

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.


#151

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.

0.6.0

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


#152

@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.


#153

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.

0.6.1

Contributors: Brian Anderson, Diggory Blake


#154

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


#155

@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.


#156

@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 https://aur.archlinux.org/packages/rustup/ (see comments starting from Svenstaro’s post at 2016-08-25 14:11), or give some thoughts here that I can relay?


#157

@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.


#158

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.

Thoughts

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.