Why is my rustup rust-toolchain file not overriding the default?

Question

I want to use the Rust "nightly" build to work with Arrow and Datafusion. According to this post and the rustup book I should be able to put a rust-toolchain file in the home directory of the project containing just the word "nightly" and that should make it the default build for that project. However, this isn't working.

Any suggestions of what I am missing?

When I check the default, I see that it is using the "stable" build.

(base) Apples-MBP:data_fusion_tutorial Daniel$ rustup default
stable-x86_64-apple-darwin (default) 

Here is what my project directory looks like:

(base) Apples-MBP:data_fusion_tutorial Daniel$ ls -a
.       ..      .git        .gitignore  Cargo.lock  Cargo.toml  rust-toolchain  src     target

If I run

rustup override set nightly

then the project builds ok, but the default is still "stable".

Answer 1

If you're on macOS, make sure rust as installed by Homebrew is not being used, by running the following:

which cargo

If it outputs something like /opt/homebrew/bin/cargo, try uninstalling Homebrew rust (brew uninstall rust), then run which cargo again - it should output something like /Users/jameshiew/.cargo/bin/cargo, and cargo --version should output the version according to your rust-toolchain.toml.

Answer 2

The rustup show command is super helpful for identifying the problem. For me the issue was that my global settings in ~/.rustup/settings.toml were overriding the project settings. Running rustup override unset fixed it for me.

Answer 3

rustup default prints the global default toolchain. You can run rustup show to get the active toolchain for the current directory:

$ rustup show

installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu

active toolchain
----------------
rustc 1.48.0 (7eac88abb 2020-11-16)

Setting a directory override will modify the active toolchain:

$ rustup override set nightly
$ rustup show

installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu

active toolchain
----------------
nightly-x86_64-unknown-linux-gnu (directory override for '/currentproject')
rustc 1.50.0-nightly (e792288df 2020-12-05)

Notice how stable is still the default toolchain, but the active toolchain changed to nightly. To change the global default, you can run the default command:

$ rustup default nightly
$ rustup default
nightly-x86_64-unknown-linux-gnu (default)

Answer 4

Do a rustup update and this should work.

Answer 5

I'm having a similar issue.

$ cat rust-toolchain.toml
[toolchain]
channel = "nightly"
$ rustup show
Default host: aarch64-apple-darwin
rustup home:  /Users/n8henrie/.rustup

installed toolchains
--------------------

stable-aarch64-apple-darwin (default)
nightly-aarch64-apple-darwin

active toolchain
----------------

stable-aarch64-apple-darwin (default)
rustc 1.50.0 (cb75ad5db 2021-02-10)

Interestingly, if I remove the .toml extension, it works:

$ mv rust-toolchain{.toml,}
$ rustup show
Default host: aarch64-apple-darwin
rustup home:  /Users/n8henrie/.rustup

installed toolchains
--------------------

stable-aarch64-apple-darwin (default)
nightly-aarch64-apple-darwin

active toolchain
----------------

nightly-aarch64-apple-darwin (overridden by '/path/to/cwd/rust-toolchain')
rustc 1.52.0-nightly (3a5d45f68 2021-03-09)

It certainly looks like the toml extension should be fine, not sure why it doesn't work:

In these cases the toolchain can be named in the project's directory in a file called rust-toolchain.toml or rust-toolchain.

https://rust-lang.github.io/rustup/overrides.html?#the-toolchain-file

It also works for me with just the word nightly, so I'm not sure why it's not working for you, but it seems like there might be a few quirks here.

Perhaps you could try the TOML syntax with file named rust-toolchain?

EDIT: Looks like the .toml extension is a recent development, perhaps the updates to the book were released before the updates to the tool.

EDIT2: Most recent rustup release is 1.23.1 from 20201202, which is what I'm running, so my issue probably lies here. What version of rustup are you running?

https://github.com/rust-lang/rustup/releases