What control are you expecting? And what do you mean that you can choose where to install rustup? There aren't any options to configure the installation location.
These commands were just added in 0.1.10 which was just published minutes ago. I've filed a PR to make the README more consistent.
Your second command is the right one, but it looks like it's being affected by the bug in your first report where the toolchain naming scheme changed. Probably if you run rustup default nightly it will fix the name of the default toolchain and make this work again. If it continues to be broken I'd just delete ~/.multirust.
This contains fixes for the most egregious problems with the new TLS stack on Windows, particularly the long hangs during download. I’m going to try to get another build out later today that converts from hyper to curl to solve the Windows TLS problem better.
I haven’t read most of this thread, but I think no one tested it with the new Linux subsystem in Windows. I just tried it, but sadly it doesn’t really work. When running the installer sh script, everything is still working pretty nicely, except for one warning:
warning: could not delete temp directory: /home/lukas/.multirust/tmp/r9wblabla_dir
The installer ends with a green “stable installed (error reading rustc version)”. Trying to run rustc -V doesn’t print anything and ends with error code 1. This makes cargo unusable because it apparently always checks rustc -vV on startup. rustup -V works, though.
I know, the Windows Ubuntu bash is still beta (just like rustup), but here is the information. If I can help somehow by testing something, just tell me
So it looks like I tricked myself into believing that rustup would allow me to host different versions side by side.
I started rustup out of curiosity (I’m on Windows in case that matters) and saw that it has this toggle for setting the path (or not). So I thought to myself that since my current installation from MSI is in c:\rust18 then I’m safe to grab nightly since it goes into %USERPROFILE%\.cargo. So as long as my “nightly console” goes through a script that updates my %PATH% from default installation to rustup one, I should be fine.
This wasn’t the case and now I’m inclined to believe that this wasn’t rustup’s intention to begin with. Cargo registry is now common for both installations which bit me a moment ago. I guess I have three questions as a consequence of this experience:
Shouldn’t MSI installation end up entirely in the path provided by the user? Yes, I know, this isn’t directly rustup related (unless it is).
Was my expectation of SxS rust installations inflated?
Would it be possible to teach rustup to set the SxS builds up?
This is true of all of Rust! The 'could not delete temp directory' problem is likely a bug in std (or a bug in std's non-existent workarounds for microsoft's beta compatibility layer!).
Probably the best thing to do is verify that Rust passes its own test suite in this environment (I am certain it does not).
This situation should work fine with the exception that Cargo may sometimes invalidate some state when it detects the toolchain changing. I'm actually not clear on when this happens or what gets deleted. rustup itself depends on shared .cargo working because it shares it with all of its own installed toolchains.
I'm not sure I understand the question. If you are suggesting that the MSI installation should get it's own .cargo directory, then at least currently the answer is no - that directory is actually expected to be shared by multiple versions of cargo (though I also have some reservations about how reliable this can be). If we continue sharing the .cargo directory it may make sense for cargo to eventually figure out how to keep per-version caches.
rustup is very much designed to enable SxS installation (assuming you mean SxS in the general sense and not an MS-specific sense), but through rustup. It doesn't make any affordances for rust compilers installed via other mechanisms, but I have vague plans to make it interoperate better over time. I'd suggest that whatever rust you had installed via the msi's you should uninstall and reinstall with rustup install. Then they will be installed SxS, but all within rustup.
I am still unclear on why you would want to install both from the msi's and rustup and what you might expect the interactions between them to be.
[quote="brson, post:130, topic:3316"]
This situation should work fine with the exception that Cargo may sometimes invalidate some state when it detects the toolchain changing. I'm actually not clear on when this happens or what gets deleted.[/quote]
I see. My experience was that a piece of code written on 1.8 that used to work (it depends on a bunch of crates) stopped building after SxS (yes, in general sense) installation of nightly.
I don't know if it is possible to check after the fact whether this is coincidental (and, IDK, one of the cargos got updated or something) or rustup installation caused this. But based on your answer I should probably stop mixing MSI and rustup installation altogether. I'll uninstall everything and try to reproduce my problem. Anything I should keep in mind looking for a repro?
Yes, this is what I was wondering about. Guidelines for the installation experience on Windows are convoluted and I get it why rarely installers do the right thing. What you're describing (as much sense as it makes from the Rust point of view) defies some of the expectations. I'm not sure if this is the right thread for me to dissect what's wrong but I'd be more than happy to write up what I think should change and why (based on platform guidelines) if you're interested.
Either way, thanks for your reply, I'll switch to rustup entirely and see how concurrent installations work for me without MSI.
On Windows, I had a bunch of versions of Rust installed before installing rustup. rustup doesn’t notice that those other versions of Rust are installed and ahead of it on the path. rustup thinks, for example, that it is changing the default version of rustc for you, but really you are stuck using the old version that was installed before rustup.
I think it would be nice if rustup noticed that which rustc and which cargo aren’t what it manages, and warn about it, to avoid this confusion.
Hi, sorry for the late response. I went on vacation! Just determining whether its an interaction between the msi installers and rustup would be a good start.
I am trying to build a dylib with statically linked dependencies on linux with the musl target and rustup, as in the example in Taking Rust everywhere with rustup, but getting strange panics from cargo. Can anyone help?
`$ rustup target add x86_64-unknown-linux-musl
info: component ‘rust-std’ for target ‘x86_64-unknown-linux-musl’ is up to date
$ cargo build --target=x86_64-unknown-linux-musl
thread ‘’ panicked at ‘assertion failed: !ret.is_empty()’, src/cargo/ops/cargo_rustc/context.rs:340
note: Run with RUST_BACKTRACE=1 for a backtrace.`
Edit Btw, I have build.rs file and am using the gcc crate to compile some C into the lib.
Just a quick update on what’s going on with rustup. Since the blog post was published over a month ago I took a vacation and have been focused on other things. I know there are some glaring bugs right now (like rustup uninstall not working - use rustup remove instead).
There’s been a steady stream of patches, but I haven’t published a new build yet. Now that rustup is ‘in production’ I’m quite scared of breaking upgrades, and the next upgrade is going to have some big metadata changes. The test suite does not have enough coverage to give me confidence in upgrades (e.g. just before the blog post I completely broke networking on Windows for a week), so I’m trying to hold off on new releases until rustup has a robust set of live upgrade tests. I’ll keep you updated and try to get the upgrades moving again soon.
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.
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.
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?