-
Notifications
You must be signed in to change notification settings - Fork 893
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
Document (and perhaps change) interaction between rust-toolchain.toml
and other override sources for components and targets
#3483
Comments
rust-toolchain.toml
and other override sources for components and targets
Hello!
The current doc says "The toolchain is chosen in the order listed above..." so I'd expect
I agree that leaving the directory dirty is not elegant. In order to prevent an XY problem and to better understand your usecase, may I ask what exactly did you want to achieve with this Finally, thanks a lot for your report! |
Most configurations of this kind (e.g. Additionally, the Practically, with knowledge of history, the document reads like “nobody adjusted it to explain this interaction after the support for specifying more than a channel name in the file was added”. Hence I experimented to find out which way it went, and was disappointed with the answer. Regarding changing the documentation, all I want is a sentence, in the introduction or the section on the
The previous situation:
It occurred to me that creating a I don't actually want to pin the toolchain channel at all — my project uses stable Rust and “latest stable” is of course the default assumption. But the place for specifying targets and components is also the place for overriding the channel.
My CI builds my project with multiple Rust toolchains so that I can test nightly and beta, because I have found this to be an effective way to discover new Rust bugs and report them before they reach stable. So, the thing I want here is to be able to separately
without either of these two configurations defeating each other. And I think that this could be done very straightforwardly by allowing the rest of the file configuration to apply even if the toolchain has been overridden; I don't see how this would ever be undesirable. I recognize that I'm not using this feature as originally imagined; what I'm proposing is that it be slightly adjusted to be useful in more scenarios. |
@kpreid Thanks for your detailed explanation!
@rbtcollins will this potential change break our compatibility promises? |
Claiming this issue on @rbtcollins' approval of implementing this idea. |
Possibly related: rust-lang/cargo#11957 |
Just for awareness, I ran into an issue with a That's probably worth documenting if intentional. Otherwise hopefully something that'll be addressed as a bug fix 😅 |
Problem you are trying to solve
It occurred to me that, even though I am using stable Rust, I could use a
rust-toolchain.toml
file to declare the targets and components my project requires, making it more convenient to use. So, I did this, and also replaced the part of my CI configuration which ran explicit rustup commands withrustup override set "${{ matrix.toolchain }}"
.This then failed, revealing to me that
rustup override set
appears to cause therust-toolchain.toml
file to be completely ignored, even though the file can specifytargets
andcomponents
whichrustup override set
cannot.Solution you'd like
Notes
The workaround I've found to get the effect I wanted is
sed -i "s/stable/${{ matrix.toolchain }}/" rust-toolchain.toml rustup show
which isn't elegant and leaves the working tree modified.
The text was updated successfully, but these errors were encountered: