`rust-toolchain.toml`: support multiple channels, or rather support nightly AND stable version.

[Sajjon]

Problem

My team prefers cargo +nightly fmt for 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.toml does not support this, but I would like it to be supported.

What do you think?

Proposed Solution

Bikeshedding syntax/overall idea:

[toolchain]
nightly = "2024-12-14"
stable = "1.87.0"

And then when I run cargo +nightly the "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:

[toolchain]
nightly = "2024-12-14"

and

[toolchain]
stable = "1.87.0"

are valid.

[ehuss]

@rustbot transfer rustup

[djc]

See also:

• Allow specifying multiple toolchains in rust-toolchain.toml file, with first as default, with auto-installation for all. #3546

[rami3l]

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 install command 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.

[xoviat]

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.

[rami3l]

@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 +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.

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 +toolchain syntax 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.

[xoviat]

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.