You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'll preface this by saying that this issue is not blocking me in any way right now, but I noticed it while debugging some other issues I had so I'm reporting it now.
There's actually two issues I see here:
install-rustfmt task does not take into account what toolchain is being used. If rust-fmt is only installed for stable, and you are running with nightly, install-rustfmt will not try to install the component for the nightly toolchain.
Since nightlyrustfmt is not installed, I would expect that when cargo make executes something requiring it, it should fail. Instead, cargo-make defaults to using the stable version instead. I am unsure why when cargo-make executes Execute Command: "rustup" "run" "nightly" "cargo" "fmt", it has different behaviour that invoking the command (rustup run nightly cargo fmt) directly.
> rustup uninstall nightly
> rustup install nightly --profile minimal
> cargo make fmt-version
cargo-make]INFO - cargo make 0.37.11[cargo-make]INFO - Calling cargo metadata to extract project info
[cargo-make]INFO - Cargo metadata done
[cargo-make]INFO - Project: cargo-make
[cargo-make]INFO - BuildFile:Makefile.toml[cargo-make]INFO - Task: fmt-test
[cargo-make]INFO - Profile: development
[cargo-make]INFO - RunningTask: legacy-migration
[cargo-make]INFO - ExecuteCommand:"rustup""run""nightly""cargo""fmt""--version"
rustfmt 1.7.0-stable(7cf61ebd 2024-03-27)[cargo-make]INFO - BuildDonein6.10seconds.
> rustup run nightly cargo fmt --version
error:'cargo-fmt.exe' is not installed for the toolchain 'nightly-x86_64-pc-windows-msvc'.To install, run `rustup component add --toolchain{toolchain}rustfmt`
The above snipping shows both problems. install-rustup did not install the nightly version of rustfmt, and cargo-make is for some reason behaving different from manually running the command (ie. its using stable rustfmt instead of erroring).
The text was updated successfully, but these errors were encountered:
@wmmc88 rustfmt tasks are a mess!
it has to do with the history of it which rustfmt changed the way you install rustfmt few years back and started to have a nightly and non nightly ways and all that. it was a huge mess!
i had a workaround for nightly or stables, with rustup or with cargo install or with install from git.
at the end, even that broke due to changes in rustfmt and i left this:
which is not amazing either.
if you want to PR the way rustfmt is installed in a way that it supports the current toolchain correctly, i would love a PR for it. i stopped chasing them.
the main goal is having it work correctly in CI flow when running for example in github actions each time with different rust toolchain (even this repo tests on stable, beta and nightly) without it breaking and working for all (right now i disabled it due to the installation issues and only use it in my dev machine where it works ok since i'm always on nightly)
Describe The Bug
I'll preface this by saying that this issue is not blocking me in any way right now, but I noticed it while debugging some other issues I had so I'm reporting it now.
There's actually two issues I see here:
install-rustfmt
task does not take into account what toolchain is being used. Ifrust-fmt
is only installed forstable
, and you are running withnightly
,install-rustfmt
will not try to install the component for the nightly toolchain.nightly
rustfmt
is not installed, I would expect that when cargo make executes something requiring it, it should fail. Instead,cargo-make
defaults to using the stable version instead. I am unsure why whencargo-make
executesExecute Command: "rustup" "run" "nightly" "cargo" "fmt"
, it has different behaviour that invoking the command (rustup run nightly cargo fmt
) directly.To Reproduce
The above snipping shows both problems.
install-rustup
did not install the nightly version ofrustfmt
, andcargo-make
is for some reason behaving different from manually running the command (ie. its using stable rustfmt instead of erroring).The text was updated successfully, but these errors were encountered: