Beta testing rustup.rs

184

While I tend to agree that there would at least be less friction if people just installed it from us, distros are going to package it - it's what they do! So I'm inclined to do what I can to make it a decent experience.

It will not. Though I can imagine why one would want that, could you say more about why that is desirable?

Is downloading and building in an arbitrary location the common way to build both user-contributed and official packages from source? IOW there's no single command that just does both? Is there any automatic mechanism for enforcing build deps, that is, that the rustc package is installed?

Does the /etc/profile.d/ script take effect automatically? I agree that this looks promising.

Publishing the binary isn't something I've considered carefully, but it does result in no proxies, which are a core part of the design, and a scenario I haven't put any consideration into until now. One could imagine being able to bootstrap the rustup install via the system cargo, then having an option to later generate the proxies. Though off the top of my head I'd prefer in this situation for the proxies to still exist and to default to the system toolchain.

185

The makepkg command is part of the pacman suite of tools, so it knows about dependencies. By default it'll refuse to build if dependencies aren't present, though there are flags to either skip that check or (using other parts of pacman) actually install the deps first.

186

Yes, for new login shells:

  • /etc/profile automatically loads all /etc/profile.d/*.sh
  • /etc/csh.login automatically loads all /etc/profile.d/*.csh
  • other shells may have their own, like /etc/fish/conf.d/
187

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.

2 Likes
188

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

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.

189

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.

190

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.

2 Likes
191

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.

192

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.

1 Like
194

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.

195

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.

196

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

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

6 Likes
197

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

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

1 Like
198

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

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

6 Likes
199

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

200

It is somewhat related to the XDG discussion:

201

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

202

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

203

Yes, that sounds doable.[quote="grossws, post:201, topic:3316, full:true"] Should also be a 0.7.0 tag in the repo at github? [/quote]

Thanks for reminding me. Done.

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

204

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

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

15 Likes