-
Notifications
You must be signed in to change notification settings - Fork 894
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
option to install toolchain version IFF it has certain components #1501
Comments
@RalfJung updated! |
It would be nice if |
@najamelan your comment consists only of quotes, looks like a formatting issue?
AFAIK if you have a component installed, rustup will only upgrade to nighties that have that component. |
@RalfJung Sorry, it needed a white line to work there.
So the point is, if I have a nightly that is one month old, with components, and I run So I think lots of people would like for rustup to update to the latest nightly that has that component. The issue is very similar for installs and updates, so I think both should considered together when trying to solve this. |
Previously, if the user had components installed on `nightly` which were not available for the latest nightly, `rustup update` would not update the user's nightly at all. With this patch, rustup will try progressively older nightlies until it finds a nightly that supports all the components the user has installed for their current nightly. Fixes rust-lang#1628. Makes progress towards rust-lang#1501. Fixes the underlying issue in rust-lang#1676.
Previously, if the user had components installed on `nightly` which were not available for the latest nightly, `rustup update` would not update the user's nightly at all. With this patch, rustup will try progressively older nightlies until it finds a nightly that supports all the components the user has installed for their current nightly. Fixes rust-lang#1628. Makes progress towards rust-lang#1501. Fixes the underlying issue in rust-lang#1676.
@najamelan that will be the behavior with #1997 :) |
Previously, if the user had components installed on `nightly` which were not available for the latest nightly, `rustup update` would not update the user's nightly at all. With this patch, rustup will try progressively older nightlies until it finds a nightly that supports all the components the user has installed for their current nightly. Fixes rust-lang#1628. Makes progress towards rust-lang#1501. Fixes the underlying issue in rust-lang#1676.
I believe this is covered by Rustup 1.20 |
Has this issue not really been fixed, or am I missing something? Right now, I am trying to add clippy to the CI of |
For nightly toolchains, the only approach I know of is to do what Miri also does when you want to run it in some project's CI:
Not sure what the nicest way is to put that into GHA. Files like https://rust-lang.github.io/rustup-components-history/x86_64-unknown-linux-gnu/miri exist for all tools, e.g. https://rust-lang.github.io/rustup-components-history/x86_64-unknown-linux-gnu/clippy. |
Thanks, I found the magic lines to be:
|
When dealing with continuous like travis, I can specify a toolchain I want to have
but not what components (rustfmt clippy) I want to install.
This means if I want to use clippy or rustfmt, I have to manually
rustup component add
it or, if the current nightly version does not ship it, try to somehow install it myself and hope it builds with the current rustc nightly.It would be great to have some kind of option "install the lastest nightly that has components x and y available" which entails potentially downgrading to a earlier nightly if the current nightly does not ship the components but the later nightly does.
Perhaps
rustup install nightly --needed-components=clippy,rustfmt
or something like that.The text was updated successfully, but these errors were encountered: