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
Setting PATH would not work for my use case. I am using pixi to set up and install the dev environment. This tool installs cargo and all the deps inside {{ workspace_folder }}/.pixi/env.
MrFoxPro, Haskely, ai-chen2050, ian-h-chamberlain, cognivore and 3 more
Ah, interesting! Yeah, currently rust-analyzer assumes that it can invoke cargo using just binary name (so, /path/to/cargo), and it doesn't support complex command like pixi run cargo. Which arguably is a design bug! We should have treated cargo as Vec<OsString>, not as PathBuf! But oh well, this now is wired up pretty thoroughly.
The current work-around would be to launch VS Code from pixi shell environment.
Alternatively, perhaps there could be a VS Code extension for pixi that cares to run pixi shell automatically? Not sure if VS Code exposes necessary hooks though.
Yes, being able to set something like CARGO pointing to ./pixi/env/cargo would be enough, but I also like the idea of being able to set pixi run cargo as well.
The current work-around would be to launch VS Code from pixi shell environment.
It would work but it's not ideal.
Alternatively, perhaps there could be a VS Code extension for pixi that cares to run pixi shell automatically? Not sure if VS Code exposes necessary hooks though
pixi is quite close to conda (but more general). The vscode team is already working to generalize conda support in vscode (xref microsoft/vscode-python#20919).
@matklad would that require a lot of work to implement your proposal? I am still learning rust, but would be happy to give it a shot if it's a low-hanging fruit. It's also a general solution that would benefit beyond pixi.
Ah, interesting! Yeah, currently rust-analyzer assumes that it can invoke cargo using just binary name (so, /path/to/cargo), and it doesn't support complex command like pixi run cargo. Which arguably is a design bug! We should have treated cargo as Vec<OsString>, not as PathBuf! But oh well, this now is wired up pretty thoroughly.
For what it's worth, I hacked up something similar for the rust-analyzer server path (which only really lives in the extension...), allowing the path to rust-analyzer be specified using something like arc rust-analyzer. While the change was a little tedious, it wasn't hard. I've been meaning to switch over to a Vec for Cargo as well, so I'm glad my impulse wasn't ill-founded.
(I havin't actually tried this, so it might need adjustmeents, but something like that should work)
Your configuration won't work directly, but setting "extraEnv" is indeed a feasible idea.
The underlying logic of switching environments in pixi is to set a series of specific environment variables and run some specific "activation" scripts if necessary. Detailed information can be found at: https://pixi.sh/latest/features/environment/#activation
Therefore, I can run "pixi shell-hook" to check the environment variables needed for activation and then manually add them to "rust-analyzer.cargo.extraEnv".
In fact, the result I get from executing "pixi shell-hook" is:
After setting this, restart the rust-analyzer plugin or reload VSCode, and you will find that the rust-analyzer plugin can check the syntax of .rs files.
However, this is still not a perfect solution. For example, clicking the RUN button still prompts:
* Executing task: cargo run --package my_rust_project --bin my_rust_project
* The terminal process failed to launch: Path to shell executable "cargo" does not exist.
Moreover, this method of manually setting the PATH is not only cumbersome (you have to set it manually for each new workspace, because pixi creates separate environment folders for each new project. ) but also inconvenient for switching between multiple Rust environments（nightly beta etc.）.
(I havin't actually tried this, so it might need adjustmeents, but something like that should work)
Your configuration won't work directly, but setting "extraEnv" is indeed a feasible idea.
The underlying logic of switching environments in pixi is to set a series of specific environment variables and run some specific "activation" scripts if necessary. Detailed information can be found at: https://pixi.sh/latest/features/environment/#activation
Therefore, I can run "pixi shell-hook" to check the environment variables needed for activation and then manually add them to "rust-analyzer.cargo.extraEnv".
In fact, the result I get from executing "pixi shell-hook" is:
After setting this, restart the rust-analyzer plugin or reload VSCode, and you will find that the rust-analyzer plugin can check the syntax of .rs files.
However, this is still not a perfect solution. For example, clicking the RUN button still prompts:
* Executing task: cargo run --package my_rust_project --bin my_rust_project
* The terminal process failed to launch: Path to shell executable "cargo" does not exist.
Moreover, this method of manually setting the PATH is not only cumbersome (you have to set it manually for each new workspace, because pixi creates separate environment folders for each new project. ) but also inconvenient for switching between multiple Rust environments（nightly beta etc.）.
A better solution is still needed!
Did you solve the RUN button click issue? Now I'm same like you. Please help
In a similar place over here; I use mise, yet another "install multiple copies of tools and dynamically select from them per-project" tool ala rbenv or nodenv or asdf. As with most cases, this interacts with VScode extensions very poorly, as they tend to implement their own binary-locating logic instead of invoking an entire shell.
I tried the above workaround:
I believe you can now use config like the following
… but still run into issues; I think possibly because other parts don't use server.extraEnv?
2025-05-16T18:19:04.311301-05:00 ERROR failed fetching toolchain version for ManifestPath { file: AbsPathBuf("/Users/ec/Sync/Code/twag/Cargo.toml") } workspace e=Failed to query rust toolchain version via `cd "/Users/ec/Sync/Code/twag" && "/Users/ec/.local/share/mise/installs/rust/1.87.0/bin/cargo" "--version"`, is your toolchain setup correctly?
2025-05-16T18:19:04.332685-05:00 ERROR failed fetching data layout for ManifestPath { file: AbsPathBuf("/Users/ec/Sync/Code/twag/Cargo.toml") } workspace e=unable to fetch target-data-layout via `cd "/Users/ec/Sync/Code/twag" && RUSTC_BOOTSTRAP="1" "/Users/ec/.local/share/mise/installs/rust/1.87.0/bin/rustc" "-Z" "unstable-options" "--print" "target-spec-json"`
2025-05-16T18:19:04.353237-05:00 ERROR FetchWorkspaceError: rust-analyzer failed to load workspace: Failed to load the project at /Users/ec/Sync/Code/twag/Cargo.toml: Failed to read Cargo metadata from Cargo.toml file /Users/ec/Sync/Code/twag/Cargo.toml, None: Failed to run `cd "/Users/ec/Sync/Code/twag" && "/Users/ec/.local/share/mise/installs/rust/1.87.0/bin/cargo" "metadata" "--format-version" "1" "--manifest-path" "/Users/ec/Sync/Code/twag/Cargo.toml"`: `cargo metadata` exited with an error: error: rustup could not choose a version of cargo to run, because one wasn't specified explicitly, and no default is configured.
help: run 'rustup default stable' to download the latest stable release of Rust and set it as your default toolchain.
This is especially odd, as both of those commands work fine in an interactive shell:
Notably, Mise "just" uses rustup, bypassing all of its own usual logic in the case of Rust; so I'm a little surprised this didn't work out-of-the-box (although my expectations with VScode extensions handling path-wrangling well are very low; it's a surprisingly difficult problem to solve …)
Activity
matklad commentedon Dec 30, 2023
In this setup, how do you invoke cargo on the CLI? You are not typing the entire
~/.pixi/env/bin/cargo, right? Is it still justcargoon the CLI?hadim commentedon Dec 30, 2023
Pixi allows you to run arbitrary commands within the new env:
pixi run cargo buildpixi run <your_command>pixi shell(spawn a new shell with all the paths set correctly)matklad commentedon Dec 30, 2023
Ah, interesting! Yeah, currently rust-analyzer assumes that it can invoke
cargousing just binary name (so,/path/to/cargo), and it doesn't support complex command likepixi run cargo. Which arguably is a design bug! We should have treatedcargoasVec<OsString>, not asPathBuf! But oh well, this now is wired up pretty thoroughly.So, the best fix here would probably be just:
#3154 (comment)
The current work-around would be to launch VS Code from
pixi shellenvironment.Alternatively, perhaps there could be a VS Code extension for
pixithat cares to runpixi shellautomatically? Not sure if VS Code exposes necessary hooks though.hadim commentedon Dec 30, 2023
Yes, being able to set something like
CARGOpointing to./pixi/env/cargowould be enough, but I also like the idea of being able to setpixi run cargoas well.It would work but it's not ideal.
pixiis quite close toconda(but more general). The vscode team is already working to generalize conda support in vscode (xref microsoft/vscode-python#20919).hadim commentedon Dec 30, 2023
@matklad would that require a lot of work to implement your proposal? I am still learning rust, but would be happy to give it a shot if it's a low-hanging fruit. It's also a general solution that would benefit beyond
pixi.davidbarsky commentedon Dec 30, 2023
For what it's worth, I hacked up something similar for the
rust-analyzerserver path (which only really lives in the extension...), allowing the path to rust-analyzer be specified using something likearc rust-analyzer. While the change was a little tedious, it wasn't hard. I've been meaning to switch over to a Vec for Cargo as well, so I'm glad my impulse wasn't ill-founded.Haskely commentedon Jul 15, 2024
Facing the same problem. Is there any progress?
matklad commentedon Jul 15, 2024
I belive you can now use config like the fololwing
(I havin't actually tried this, so it might need adjustmeents, but something like that should work)
Haskely commentedon Jul 16, 2024
Your configuration won't work directly, but setting "extraEnv" is indeed a feasible idea.
The underlying logic of switching environments in pixi is to set a series of specific environment variables and run some specific "activation" scripts if necessary. Detailed information can be found at: https://pixi.sh/latest/features/environment/#activation
Therefore, I can run "pixi shell-hook" to check the environment variables needed for activation and then manually add them to "rust-analyzer.cargo.extraEnv".
In fact, the result I get from executing "pixi shell-hook" is:
Among these, the truly important part is
export PATH="/Users/nova/rust-learn/my_rust_project/.pixi/envs/default/bin:<other paths>".Therefore, I can set "rust-analyzer.cargo.extraEnv" at the "workspace level":
{ "rust-analyzer.server.extraEnv": { "PATH": "/Users/nova/rust-learn/my_rust_project/.pixi/envs/default/bin:$PATH" } }After setting this, restart the rust-analyzer plugin or reload VSCode, and you will find that the rust-analyzer plugin can check the syntax of .rs files.
However, this is still not a perfect solution. For example, clicking the
RUNbutton still prompts:Moreover, this method of manually setting the PATH is not only cumbersome (you have to set it manually for each new workspace, because pixi creates separate environment folders for each new project. ) but also inconvenient for switching between multiple Rust environments（nightly beta etc.）.
A better solution is still needed!
ai-chen2050 commentedon Jul 23, 2024
@hadim @matklad the latest version meets this problem again. As follows:
Actually，Both rustc and cargo is located at
$HOME/.cargo/bin:$PATH. So I revert to last week's version.b0c1 commentedon Oct 7, 2024
Any fix?
ai-chen2050 commentedon Oct 7, 2024
@b0c1 reopen vscode process, maybe can fix.
DevelopJKong commentedon Oct 27, 2024
Did you solve the
RUNbutton click issue? Now I'm same like you. Please helpRunin vscode hverlin/mise-vscode#68ELLIOTTCABLE commentedon May 16, 2025
In a similar place over here; I use mise, yet another "install multiple copies of tools and dynamically select from them per-project" tool ala
rbenvornodenvorasdf. As with most cases, this interacts with VScode extensions very poorly, as they tend to implement their own binary-locating logic instead of invoking an entire shell.I tried the above workaround:
… but still run into issues; I think possibly because other parts don't use
server.extraEnv?This is especially odd, as both of those commands work fine in an interactive shell:
Output:
Are there any other workarounds?
Notably, Mise "just" uses rustup, bypassing all of its own usual logic in the case of Rust; so I'm a little surprised this didn't work out-of-the-box (although my expectations with VScode extensions handling path-wrangling well are very low; it's a surprisingly difficult problem to solve …)