Beta testing rustup.rs

[brson]

error: could not remove update hash file: ‘C:\Users\Jonas.multirust\update-hashes\nightly-i686-pc-windows-msvc’ (Das System kann die angegebene Datei nicht finden. (os error 2))

Thanks! I filed a bug.

[briansmith]

I downloaded https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-setup.exe.

Then I ran installed stable-x86_64-pc-windows-msvc and nightly-x86_64-pc-windows-msvc without issue.

Then I installed nightly-i686-pc-windows-msvc and stable-i686-pc-windows-msvc. I found it confusing that it downloaded the i686 rustc again, instead of just adding i686 support to the existing x86-64 rustc.

Then I learned on IRC that I am supposed to do rustup target add stable-i686-pc-windows-msvc and rustup target add nightly-i686-pc-windows-msvc instead, to add cross-compilation targets. But, when I did this, it failed:

error: toolchain 'stable-x86_64-pc-windows-msvc' does not contain component 'rust-std' for target 'stable-i686-pc-windows-msvc'

and

error: toolchain 'nightly-x86_64-pc-windows-msvc' does not contain component 'rust-std' for target 'nightly-i686-pc-windows-msvc'

It would be nice to have the cross-compilation to i686-msvc work. My normal workflow is to do the equivalent of cargo test --target=i686-pc-windows-msvc && cargo test --target=x86_64-pc-windows-msvc using a cross-compilation setup I did manually.

Otherwise, it was pretty convenient. It would be nice to see the rustup installer signed sooner rather than later, though I know this is annoying.

Otherwise, it seemed to work well! Pretty awesome.

[vi0]

Browsing the site from Firefix fails (Issue), from Chromium it printed curl https://sh.rustup.rs -sSf | sh.
I added -x to sh and ran it on my system (x86_64 kernel, mixed, mostly 32-bit userland from Debian mostly jessie) from a separate user.
It has installed itself and worked well.

Additional target works.
Additional toolchains and cargo not tested.

Nitpick: rustup target list show non-installable on stable targets like mips-unknown-linux-musl

Default installation weights 304M. With additional musl target - 346M.

Shall I also test using rustup.rs atop of existing multirust installation?

[jnicklas]

I had the same problem. I had multirust installed previously via homebrew. I uninstalled multirust and did an rm -rf ~/.multirust and after that everything worked as expected.

[brson]

Then I learned on IRC that I am supposed to do rustup target add stable-i686-pc-windows-msvc and rustup target add nightly-i686-pc-windows-msvc instead, to add cross-compilation targets. But, when I did this, it failed:

@briansmith it should work as expected if you instead write rustup target add i686-pc-windows-msvc (note there’s no “nightly” there). The distinction is that nightly-i686-pc-windows-msvc is a toolchain identifier whereas i686-pc-windows-msvc is a simple target triple. So what this command is doing is adding the “i686-pc-windows-msvc” target to the “nightly” toolchain for “x86_64-pc-windows-msvc”.

Thanks for the report. Interesting point of confusion.

[brson]

Nitpick: rustup target list show non-installable on stable targets like mips-unknown-linux-musl

Yeah, I discovered this too after the 1.8 release. Here’s an issue.

Shall I also test using rustup.rs atop of existing multirust installation?

No, not yet. I already know it’s pretty bad, and I’m not sure yet what I want to do to make it better. Installing over multirust is sure to be bad, so perhaps it’s best to just detect that situation and refuse to install. Opinions?

[brson]

I had the same problem. I had multirust installed previously via homebrew. I uninstalled multirust and did an rm -rf ~/.multirust and after that everything worked as expected.

Can you describe what happened in more detail after installing over multirust?

[brson]

Default installation weights 304M. With additional musl target - 346M.

Just FYI, I plan to make the rust-docs package optional soon, and not installed by default. That should cut down some of the install size.

[euclio]

I’d really love if someone smarter than me could make a package for rustup.rs for Arch Linux’s AUR. I’d really love to replace my multirust.sh package

Shouldn’t be that hard: I’m just not sure how rustup operates in a system-wide fashion. Maybe the PKGBUILD for multirust is a good starting point?

[vi0]

On Adnroid, it suggests the same command line as in Linux: curl https://sh.rustup.rs -sSf | sh

Let’s try:

$ adb shell
shell@hwH60:/data $ cd local/tmp
shell@hwH60:/data/local/tmp $ curl https://sh.rustup.rs -sSf | sh -x
/system/bin/sh: curl: not found

Not the good beginning.

Let’s force it forward:

shell@hwH60:/data/local/tmp $ ^D
$ curl https://sh.rustup.rs -sSf > rsbootstrap.sh
$ chmod +x rsbootstrap.sh
$ adb push rsbootstrap.sh /data/local/tmp/
620 KB/s (5100 bytes in 0.008s)
mvp@vi-notebook:C!/tmp$ adb shell
shell@hwH60:/ $ cd /data/local/tmp/
shell@hwH60:/data/local/tmp $ 
shell@hwH60:/data/local/tmp $ /system/bin/sh -x ./rsbootstrap.sh               
+ set -u
+ RUSTUP_UPDATE_ROOT=https://static.rust-lang.org/rustup/dist
+ main
+ need_cmd curl
+ command -v curl
+ >/dev/null 
+ 2>&1 
+ err need 'curl' (command not found)
+ say need 'curl' (command not found)
+ >&2 
+ echo rustup: need 'curl' (command not found)
rustup: need 'curl' (command not found)
+ exit 1

I think at least http://rustup.rs site should recognize Android and not offer that line for execution, instead explaining the correct way of getting Rust code running on Android.

Issue #328

[jnicklas]

Sorry, I was kind of on the go, so I didn’t investigate at all before going with the nuclear option of simply removing ~/.multirust.

Here’s what happened in as much detail as I have:

• I had multirust installed via homebrew.
• I did a brew unlink multirust ahead of the installation, I’m not sure if that’s important.
• I ran the script from rustup.rs
• I got the error: toolchain 'stable' is not installed error
• I tried various things to fix it, but I just got the same error. brew uninstall multirust did not help.
• I ran rm -rf ~/.multirust and ran the installer again, everything worked without problem

[eminence]

I noticed that the self-update happens after everything has been downloaded. Was that intentional? It seems like there might be some benefits to doing the self-update first (I’m envisioning a scenario where rustup itself needs to be updated before it can download new stuff, but fails to update because it can’t download new stuff)

[vi0]

Shall it be ~/.cache/multirust instead of just ~/.multirust (and for .cargo as well)? Is Rust against XDG?
Or has XDG’s idea about .config and .cache failed and everybody is moving back to plain old .myprogram.conf?

[Screwtapello]

I tried running rustup from behind a corporate firewall, and immediately hit a problem: apparently it doesn’t respect the $https_proxy environment variable.

Also, +1 for following XDG conventions as closely as possible on the relevant platforms.

[kainino]

I think the website needs a small “other platforms” button - like rust-lang.org - for installers for other platforms. For example, looking at the website on Linux, I wasn’t sure whether I should send it to a Windows user, since I couldn’t immediately tell if it would work for them.

[brson]

@jnicklas thansks for the details.

I noticed that the self-update happens after everything has been downloaded. Was that intentional?

@eminence There’s a technical limitation in the way that self-update works that forces the actual replacement of the rustup binary to be the last step of installation. Namely, that on windows you can’t delete the running executable, so on windows rustup is forced to use an ugly hack: it runs another copy of itself that copies the new binary into place, exiting as it does so that the running binary can be deleted a split second later (iow the actual self-upgrade happens after rustup has reported a successful update and exited). I could possibly add another update step that lets rustup run some upgrade routine before doing the self-exe-replace, but that’s scary because if the exe-replacement fails then your upgrade is in an inconsistent state. So right now self-update is as simple as possible.

Shall it be ~/.cache/multirust instead of just ~/.multirust (and for .cargo as well)? Is Rust against XDG?Or has XDG’s idea about .config and .cache failed and everybody is moving back to plain old .myprogram.conf?

Rust does not currently support XDG. Here’s a previous thread.

I tried running rustup from behind a corporate firewall, and immediately hit a problem: apparently it doesn’t respect the $https_proxy environment variable.

This is a problem in hyper. I’ll probably fix it by switching to curl.

I think the website needs a small “other platforms” button - like rust-lang.org - for installers for other platforms. For example, looking at the website on Linux, I wasn’t sure whether I should send it to a Windows user, since I couldn’t immediately tell if it would work for them.

Good idea. Issue.

[brson]

The new build contains an expanded interactive installation. Now during install you can press “a” (for “advanced”) and go through a serious of questions to customize the install. Right now the default toolchain and whether to adjust the PATH variable are the only options.

Some things that I don’t love about it is that the “a” and “n” letters for choosing “advanced” installation or to cancel, are kinda unobvious (“n” for “cancel”…), and not presented in a beautiful way.

The model of answering questions to change the configuration is kinda cumbersome, but we’re quite constrained on what can be done on the console by windows.

The total amount of text is a bit overwhelming too. It might be nice to apply some more style and layout to draw the eyes to the important information.

I’d love to have other examples to crib off of if anybody knows other interactive CLI’s that do this kind of thing well.

[brson]

I’m also curious what people think of rustup now displaying the full toolchain name, including the target:

info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'beta-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'rust-docs'
info: downloading component 'cargo'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'rust-docs'
info: installing component 'cargo'
info: syncing channel updates for '1.8.0-x86_64-unknown-linux-gnu'
info: checking for self-updates
info: rustup is up to date

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.8.0 (db2939409 2016-04-11)
    beta-x86_64-unknown-linux-gnu unchanged - rustc 1.9.0-beta.1 (37a2869af 2016-04-12)
   nightly-x86_64-unknown-linux-gnu updated - rustc 1.10.0-nightly (a0c325980 2016-04-20)
   1.8.0-x86_64-unknown-linux-gnu unchanged - rustc 1.8.0 (db2939409 2016-04-11)

This feels really verbose to me, so I’ve considered eliding the target when it is the same as the default, but at the same time showing the full toolchain name does hint that e.g. ‘nightly’ is short for something else.

[retep998]

I’m in favor of displaying the full toolchain name. The shortened versions should only ever be what the user types in, not what rustup actually does or prints out.

[themax]

I tried rustup on windows and I get the 32 bit binaries (nightly-i686-pc-windows-gnu) even though my PC is 64 bit. Is this a known issus?

Later edit:

I noticed rustup-init.exe is 32 bit also.

Another more severe issue is that rustup.exe process seem to be hanging and it cannot be killed from the Windows Task Manager. Due to this issue, I cannot remove the .cargo and .multirust directories and I have to_force_ reboote the PC to recover (using the power button).