Repository navigation
rust-toolchain.toml: support multiple channels, or rather support nightly AND stable version. #4391
Description
Activity
- Reacted by Alexander Cyon
Thanks for your report.
I believe the X problem here is that the current toolchain file mostly expresses an obligation (a "build dependency"), but some might want to use it to express a recommendation (a "dev dependency"), and it's not clear which is the case under what circumstances.
In this case it's even more peculiar: that particular nightly version is installed for formatting purposes only, so specifying "nightly" will never work, because "nightly" is a moving target, and actually I don't think anyone would want to pin their project to a moving target because that's not really pinning. The new
rustup toolchain installcommand in v1.28+ has made this situation even clearer.My conclusion is that this system might need a redesign to allow better expression of intent.
- changed the title
[-]`rust-tooolchain.toml`: support multiple channels, or rather support nightly AND stable version.[/-][+]`rust-toolchain.toml`: support multiple channels, or rather support nightly AND stable version.[/+]on Jun 25, 2025 - marked reuqest support for rust-toolchain-nightly.toml #4659 as a duplicate of this issue
on Dec 25, 2025 I believe the X problem here is that the current toolchain file mostly expresses an obligation (a "build dependency"), but some might want to use it to express a recommendation (a "dev dependency"), and it's not clear which is the case under what circumstances.
@rami3l I disagree with this characterization. The 'obligation' that I am attempting to express is either a certain stable version OR a certain nightly version. It is reasonable to target both stable and nightly versions, in order to prepare for upcoming updates to rust, and to allow downstream users to use nightly versions, if they desire.
@xoviat Thanks for the follow up. In that case the problem you are trying to solve is fundamentally different but the approaches suggested are more or less similar.
If I understand it correctly in your case you DO want to have both toolchains for the development, which is perfectly reasonable for a widely-used library for example.
Do you think it'll be helpful in your case if I add a CLI option to redirect rustup to a non-default TOML file name, so that you can choose between two different active toolchains?
Instead of
+nightlyyou'll just do+file:rust-toolchain-nightly(speculative syntax to avoid bikeshedding) or something and rustup will try to read the toml file with that name: I'm thinking about something like Docker compose. Note that in this mode the active toolchain will be the one specified in the file.I can imagine that setting it to a special value (say
+file:) would disable the TOML lookup which would allow closing another issue (#2793).PS: The rationale of overriding the
+toolchainsyntax is that it has the highest precedence. If I just implement the regular override on the toml loading path, the user might get confused about why the override doesn't work when there are other overrides above it.Instead of +nightly you'll just do +file:rust-toolchain-nightly (speculative syntax to avoid bikeshedding) or something and rustup will try to read the toml file with that name: I'm thinking about something like Docker compose. Note that in this mode the active toolchain will be the one specified in the file.
That would be perfectly fine.
Reacted by rami3l@xoviat Sorry for the late update! Based on the original idea in #4391 (comment), I've made a new proposal: #5025
Please feel free to share your thoughts!
Problem
My team prefers
cargo +nightly fmtfor formatting over stable.I have a different nightly installed locally than we have in CI, causing CI checks to fail. A solution would be to use
rust-tooolchain.toml, alas we only want to use nightly for fmt.Today
rust-tooolchain.tomldoes not support this, but I would like it to be supported.What do you think?
Proposed Solution
Bikeshedding syntax/overall idea:
And then when I run
cargo +nightlythe"2024-12-14"version will be used. But for non-nightly commands"1.87.0"is used.Notes
We can also omit either or, i.e. both:
and
are valid.