Beta testing rustup.rs

[inejge]

Well, I'd like for the rustup package to "provide" rust, so that if a package requires rust, it is sufficient for rustup to be installed.

That dependency config could indeed fail in a way you've described, but what I had in mind is different:

• The compiler is provided by the rust package, which depends on rust-system-proxies.

• The rustup package depends on rust.

• When rustup is first installed, the proxies still execute the system rust binaries. Any attempt to use rustup tells the user to run rustup init.

• After rustup init, the system rust is linked to the system toolchain, which is set to be the default, so there's still only one copy of the compiler, the system one, and it's used automatically.

• Only after the user installs another toolchain and sets it as default, running bare rustc will invoke the non-system compiler. The use of the system-provided tools can be requested by setting USE_SYSTEM_RUST.

that way I don't have to install both rustup and rust, keeping two copies of rust on my system

You wouldn't have two copies unless you explicitly install another.

[matklad]

ls $(rustc --print-sysroot)/lib/rustlib/src/rust

First, correction: it should be --print sysroot, without the third -

And a question/suggestion: can I hope that I find sources there even if rustup is not used to manage rust installation? It would be really nice if say, distros or the windows installer had an option to install rust sources, and that the sources would be paced to sysroot/lib/rustlib/src/rust.

[brson]

And a question/suggestion: can I hope that I find sources there even if rustup is not used to manage rust installation? It would be really nice if say, distros or the windows installer had an option to install rust sources, and that the sources would be paced to sysroot/lib/rustlib/src/rust.

It could be added as an option to the windows installer, though rustup will eventually basically become the windows installer. For distros, I don't have any specific knowledge about their plans, but I consider this arrangement of the standard library source code to effectively be part of the broader Rust platform definition, and would strongly encourage them to support it in some way. sysroot/lib/rustlib/src is the canonical location to find the source to the standard library.

This reminds me that wouldn't it be great to have rust packaging guidelines.

[kornel]

At company where I worked we had system administrators who insisted on using only packages from the distro. Getting an RPM installed was easy (especially if it was outdated enough to be blessed by RedHat ). Using curl | sh for something in production has been intentionally made very difficult both politically and technically.

I think there's a huge value in distros packaging Rust — it adds to its legitimacy, and reduces friction for adoption even in "Serious Business" environment.

[kornel]

I use distro-packaged rustc for "stable" (deploying things to production), and if I need to test something on beta/nightly I use rustup (only in dev).

Having rustup play nicely with distro-packaged rustc is helpful, because sometimes I want to try beta/nightly on VMs that have distro-packaged rustc installed already.

Changing PATH is fine (it's a minor annoyance, because rustup only modifies .profile, so I have to manually copy it to .bashrc).

I would never use rustup to switch versions of distro's rustc for use in production. Distros have appropriately versioned packages (e.g. look at PHP — you have both minor versions and families of packages for different major versions), and people using distros already have to have solutions for managing versions, updates and deployments. Having rustup in the mix, doing versioning and updates differently, would only make things harder.

[notriddle]

Honestly, I have to agree with @kornel. The distro's package building scripts should use the distro's compiler and avoid using anything installed by rustup (rustup, in turn, should avoid putting its stuff where the package manager will find it, or being marked as providing a copy of the rust compiler). That way, everybody's package managers don't need to learn how to interface with it, or it with them.

[dns2utf8]

I do not agree, because it would require an alias to use rustup then.

In my opinion the best would be if there were a package for rustup in the distro.
Then the two packages were able to conflict each other.

[hsivonen]

Ideally, rustup would not add rustc and cargo to the path but instead have its toolchains be accessible through rustup itself (rustup rustc, rustup cargo) or through different commands as rustc and cargo. This clearly indicates we are not using the system rustc or cargo but rustup's rustc or cargo instead.

I think this is backwards in terms of ergonomics. The user who is developing Rust code should be able to type cargo without anything extra and get the fresh Cargo from rustup.rs backed by the fresh rustc from rustup.rs.

It should be the distro's responsibility to make sure that building its packages from source using its package manager use the Cargo/rustc version that the distro wants to use. It doesn't matter if those invocations are prefixed or postfixed, since it won't be the user typing the invocations directly.

[brson]

rustup 0.6.4 is out. Upgrade with rustup self update.

It's been a while. This is mostly bug fixes, but it does come with one goodie: rustup can generate shell completions for bash, zsh, and fish (thanks @kbknapp).

This should also fix the occasional issues with checksum failures on updates. With that bug out of the way I'm going to focus on releasing rustup 1.0 and making rustup the primary installation mechanism for Rust. This will mostly entail bumping the version number and updating the main website's download page, but I'll also probably do a once-over of the issue tracker and see if there's any last-minute polish to be done.

I do think there's a whole lot of work left to do to make rustup really great, but it's about time to bite the bullet and get a major release out. After 1.0, future work will involve getting back to "NDK" support, signing, bugfixing, and packaging of additional tools. In the future I would like to do another pass at the CLI design - I think the basic UI could be cleaner still, the commands more predictable.

0.6.4

• making rustup prepend cargo bin to path instead of append
• Use released version of rustls dependency
• Update OpenSSL
• Made outputting of ANSI terminal escapes codes defensive
• Adjusted rustup-init.sh need_cmd to add uname and remove printf
• Update to error-chain 0.5.0 to allow optional backtrace
• Fix variable naming in rustup-init.sh
• Update clap to fix --help formatting
• Add an FAQ entry about troubles with antivirus
• Clarify how rustup toolchain installation works on Windows
• Do not interpret commas when using "rustup run"
• Fix local declarations for zsh completions
• Fix checksum failures
• Treat an empty CARGO_HOME the same as an unset CARGO_HOME
• Check stdout is a tty before using terminal features
• Add completion generation for zsh, bash and fish shells

Contributors: Alex Crichton, Andrew Koroluk, Brian Anderson, Chungmin Park,
Diggory Blake, Guillaume Fraux, Jake Goldsborough, jethrogb, Kamal Marhubi,
Kevin K, Kevin Rauwolf, Raphael Cohn, Ricardo Martins

[brson]

rustup 0.6.5 is out. Upgrade with rustup self update.

This release includes a new version of curl, which fixes a number of security issues. Please upgrade.

0.6.5

• Update bundled curl code
• Remove old zsh completions
• Fix two small typos in the error descriptions
• Update README
• Fix name of bash completion directory

Contributors: Alex Crichton, Björn Steinbrink, Brian Anderson, Jian Zeng, Matt
Brubeck

[brson]

rustup 0.7.0 is out. Run rustup self update to update.

This release is mostly bugfixes and preperation for rustup 1.0. The
big change here is that I've finally moved the ~/.multirust directory
to ~/.rustup. It should happen transparently, but because of the
history of rustup.sh and multirust.sh there's a lot of branchy
special-cases. Let me know if anything blows up. For now ~/.multirust
remains a symlink to ~/.rustup for the sake of any tools that expect
it to exist, but I don't intend to leave that forever.

@xenOn has been doing a lot of the difficult work to make rustup
support mips. Thanks @xenOn.

If all goes well, rustup will be 1.0 in time for the Rust 1.14 release
next week.

0.7.0

• Correctly "detect" host endianness on MIPS
• Add powershell completions
• Update toolchain used to build rustup
• Support probing MIPS64 n64 targets
• Support MIPS architectures in rustup-init.sh
• Automatically detect NetBSD during standard install
• Fix symlink creation on windows
• Search PATH for binaries run by rustup run
• Recursive tool invocations should invoke the proxy, not the tool directly
• Upgrade error-chain
• Add FAQ entry for downloading Rust source
• Rename ~/.multirust to ~/.rustup
• Remove some codegen hacks
• Update libc for MIPS64 host builds
• Default to MSVC on Windows

Contributors: Alex Crichton, Arch, bors, Brian Anderson, Diggory Blake, Kai
Roßwag, Kevin K, Oliver Schneider, Ryan Havar, Tobias Bucher, Wang Xuerui

[josh]

To make distribution packaging easier, could rustup automatically install its proxy binaries to ~/.local/bin, which many distributions automatically put in $PATH if it exists? That would let /usr/bin/rustc and /usr/bin/cargo refer to the distro-installed versions (for use by distro packages and users who don't use rustup), while any user who uses rustup will have the proxies in their $PATH ahead of /usr/bin.

rustup as packaged in a Linux distribution should definitely never have its proxies installed system-wide, where a distribution Rust package could accidentally build with them. Those should stay in a user directory, which the user can then have on their $PATH.

(Also, at least in Debian, we definitely plan to package rustup, because it provides the simplest way for users to test nightly or to install a cross-compiler toolchain for an arbitrary target platform.)

[matklad]

To make distribution packaging easier, could rustup automatically install its proxy binaries to ~/.local/bin, which many distributions automatically put in $PATH if it exists?

It is somewhat related to the XDG discussion:

Let Cargo put data into platform-specific directories

Make Cargo obey platform-specific directory standards

Issue: Consider moving to platform-specific configuration directories

[grossws]

Should also be a 0.7.0 tag in the repo at github?

[Eh2406]

Is it just me or did color stop working on windows?

[brson]

To make distribution packaging easier, could rustup automatically install its proxy binaries to ~/.local/bin, which many distributions automatically put in $PATH if it exists?

Yes, that sounds doable.

Should also be a 0.7.0 tag in the repo at github?

Thanks for reminding me. Done.

Is it just me or did color stop working on windows?

I see colors running rustup-init.exe under cmd.exe.

[brson]

rustup 1.0.0 is out. Run rustup self update to update.

This is the first major release of rustup.

This release is an acknowledgement that rustup is the preferred tool
for installing Rust, and that it is reliable enough for general use. At
this point rustup will become the recommended installer for Rust,
though all existing installation methods will remain.

There is yet more work to be done on rustup. It has plenty of bugs,
some features unimplemented, and could benefit from more polish.
Near-term priorities are on adding a GUI installer for Windows,
improving security of Rust installation with signing, and on enabling
rustup and tools like xargo to cooperate to provide a more integrated
cross-compilation experience.

rustup has been in development in some form for a while and has
benefited greatly from community collaboration. Thanks to Diggory
Blake for creating rustup, and thank you to everyone who has
contributed, tested, and provided feedback!

1.0.0

• Statically link MSVC CRT
• Upgrade ~/.multirust correctly from rustup-init

Contributors: Alex Crichton, Andrew Koroluk, Arch, benaryorg, Benedikt Reinartz,
Björn Steinbrink, bors, Boutin, Michael, Brian Anderson, Cam Swords, Chungmin
Park, Corey Farwell, Daniel Keep, David Salter, Diggory Blake, Drew Fisher,
Erick Tryzelaar, Florian Gilcher, geemili, Guillaume Fraux, Ivan Nejgebauer,
Ivan Petkov, Jacob Shaffer, Jake Goldsborough, James Lucas, Jeremiah Peschka,
jethrogb, Jian Zeng, Jimmy Cuadra, Joe Wilm, Jorge Aparicio, Josh Machol, Josh
Stone, Julien Blanchard, Kai Noda, Kai Roßwag, Kamal Marhubi, Kevin K, Kevin
Rauwolf, Kevin Yap, Knight, leonardo.yvens, llogiq, Marco A L Barbosa, Martin
Pool, Matt Brubeck, mdinger, Michael DeWitt, Mika Attila, Nate Mara, NODA, Kai,
Oliver Schneider, Patrick Reisert, Paul Padier, Ralph Giles, Raphael Cohn, Ri,
Ricardo Martins, Ryan Havar, Ryan Kung, Severen Redwood, Tad Hardesty, Taylor
Cramer, theindigamer, Tim Neumann, Tobias Bucher, trolleyman, Vadim
Petrochenkov, Virgile Andreani, V Jackson, Vladimir, Wang Xuerui, Wayne Warren,
Wesley Moore, Yasushi Abe, Y. T. Chung

[Manishearth]

rustup 1.0.0 is out

I mentioned this yesterday, but I really think that gpg-signing both the sh.rustup.rs script and the rustup binary is a must for a 1.0 release.

Can this be done? (Including making sh.rustup.rs check the signature of the binary, and keeping the signature of the sh script on the site somewhere)

[brson]

Well, no, gpg signing cannot be done for rustup 1.0. It is literally impossible since 1.0 is released.

The reason I don't consider signing a blocker for rustup 1.0 is because the current installers today are not properly verified either, so it is not a degradation in service (although rustup.sh will do verification, it does not guarantee it). For those who were manually verifying the signatures of the old installers, that option remains available.

I do believe that having proper end to end signing of all Rust artifacts is important, and I wish it was done by now, but it is not simply a matter of applying gpg to the problem. There are some details about the plan in this thread.

Edit: from re-reading your message @Manish I gather that you would like me to just retroactively publish sigs for these specific files, not generally solve signing for Rust installation. That's technically possible, but I don't think it achieves much security-wise. Since rustup itself downloads and installs executables, without verifying those signatures there's still a bunch of unverified code running on your system. I'm not inclined to make such changes to the release process on the spot.

[Manishearth]

I gather that you would like me to just retroactively publish sigs for these specific files,

yeah, that was the case. I do want a long term solution but I am not fond of a non-beta project that uses curl | sh to not have additional crypto (other than https) backing it.

I see your concerns.