@youknowone
Is the CI error in WASM related to the current PR?
https://github.com/RustPython/RustPython/actions/runs/4373906862/jobs/7652708971

Should we specify Rust version in rust-toolchain instead of Cargo.toml?
The current config may only apply to the main package, while not affecting other packages in the workspace.

@xiaozhiyan the ci error should be a different issue. Something to do with trying to get nodejs when new versions are released though I haven't really looked into it.

I see. Then I'll ignore the CI error for WASM.

How about the location of setting Rust version?

Should we specify Rust version in rust-toolchain instead of Cargo.toml?
The current config may only apply to the main package, while not affecting other packages in the workspace.

The current config may only apply to the main package, while not affecting other packages in the workspace.

I think you might be right here, we might need to explicitly inherit these like we do for the deps.

I think https://github.com/RustPython/RustPython/blob/main/rust-toolchain may be the convenient place to specify Rust version. Otherwise we'd better remove the rust-toolchain file to avoid version conflict in the future.

I would usually specify rust-toolchain.toml file in the project root as follows,

[toolchain]
channel = "1.67.1"

I don't think that currently fails the build if only specified in rust-toolchain, looking through blame, rust-toolchain was added for actions-rs/toolchain to work better.

We generally do always bump to the most recent version released so having stable in rust-toolchain and bumping rust-version shouldn't be too hard (though it would be nice if rust-version could be used by the action).

I think rust-toolchain.toml may be a suggested way to specify Rust version of a project (maybe including multiple packages), which is respected by Cargo and is not specific to particular CI tool or script.
https://rust-lang.github.io/rustup/overrides.html#the-toolchain-file

Btw, Rust 1.68.0 was just officially released, but maybe it would not cause compatibility issue with current config.

Ah, it does get respected but it doesn't fail. Instead it automatically uses the appropriate version if it already exists or does a download of the more recent version automatically.

I'd personally prefer to let the user make that decision on their own after getting a build error but I could also see how this would work.