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.
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.
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.
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.
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.
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.
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.
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.
CARGO_HOME the same as an unset CARGO_HOMEContributors: 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
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.
Contributors: Alex Crichton, Björn Steinbrink, Brian Anderson, Jian Zeng, Matt Brubeck
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.
rustup runContributors: Alex Crichton, Arch, bors, Brian Anderson, Diggory Blake, Kai Roßwag, Kevin K, Oliver Schneider, Ryan Havar, Tobias Bucher, Wang Xuerui
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.)
It is somewhat related to the XDG discussion:
https://github.com/rust-lang/cargo/pull/2127 https://github.com/rust-lang-nursery/rustup.rs/issues/247
Should also be a 0.7.0 tag in the repo at github?
Is it just me or did color stop working on windows?
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.
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!
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
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)
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.
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.