Call the right cargo binary

[mejrs]

For some reason it calls the wrong cargo binary, resulting in this error:

error: no such subcommand: `+nightly`

[messense]

+toolchain is only available when using cargo installed with rustup.

rustup cargo

$ cargo --help
Rust's package manager

USAGE:
    cargo [+toolchain] [OPTIONS] [SUBCOMMAND]
...

$ ls -l `which cargo`
lrwxr-xr-x  12 messense  staff  29 Jun 17 18:29 /Users/messense/.cargo/bin/cargo -> /opt/homebrew/bin/rustup-init

standalone cargo

$ /opt/homebrew/bin/cargo --help
Rust's package manager

USAGE:
    cargo [OPTIONS] [SUBCOMMAND]
...

$ /opt/homebrew/bin/cargo +nightly list
error: no such subcommand: `+nightly`

[mejrs]

That's the weird thing - I have it installed correctly and it works fine in powershell. It just doesn't work when invoked from Rust using Command.

[davidhewitt]

Is there some PATH trickery going on which means that standalone cargo has ended up ahead of the rustup installed one when the command is being executed?

[adamreichold]

Is there some PATH trickery going on which means that standalone cargo has ended up ahead of the rustup installed one when the command is being executed?

I think it would be interesting to dbg!(std::env::var("PATH")); from the xtask binary to see whether this differs from what PowerShell is using.

[mejrs]

Is there some PATH trickery going on which means that standalone cargo has ended up ahead of the rustup installed one when the command is being executed?

I think it would be interesting to dbg!(std::env::var("PATH")); from the xtask binary to see whether this differs from what PowerShell is using.

In this case that would be:

C:\\Users\\bruno\\Rust\\pyo3\\target\\debug\\deps;
C:\\Users\\bruno\\Rust\\pyo3\\target\\debug;
C:\\Users\\bruno\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib;
C:\\Users\\bruno\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\bin;
C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.2.6.0_x64__8wekyb3d8bbwe;
C:\\Users\\bruno\\.cargo\\bin;
C:\\Windows\\system32;
C:\\Windows;
C:\\Windows\\System32\\Wbem;
C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;
C:\\Windows\\System32\\OpenSSH\\;
C:\\Program Files\\NVIDIA Corporation\\NVIDIA NvDLISR;
C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common;
C:\\Program Files\\Git\\cmd;
C:\\Program Files\\LLVM\\bin;
C:\\WINDOWS\\system32;
C:\\WINDOWS;
C:\\WINDOWS\\System32\\Wbem;
C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;
C:\\WINDOWS\\System32\\OpenSSH\\;
C:\\Users\\bruno\\AppData\\Local\\Programs\\Python\\Python310\\Scripts\\;
C:\\Users\\bruno\\AppData\\Local\\Programs\\Python\\Python310\\;
C:\\Users\\bruno\\AppData\\Local\\Microsoft\\WindowsApps;
C:\\Users\\bruno\\AppData\\Local\\Programs\\Microsoft VS Code\\bin"

But $env:PATH gives:

C:\Program Files\WindowsApps\Microsoft.PowerShell_7.2.6.0_x64__8wekyb3d8bbwe;
C:\Users\bruno\.cargo\bin;
C:\Windows\system32;
C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
C:\Windows\System32\OpenSSH\;
C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;
C:\Program Files\Git\cmd;
C:\Program Files\LLVM\bin;
C:\WINDOWS\system32;
C:\WINDOWS;
C:\WINDOWS\System32\Wbem;
C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
C:\WINDOWS\System32\OpenSSH\;
C:\Users\bruno\AppData\Local\Programs\Python\Python310\Scripts\;
C:\Users\bruno\AppData\Local\Programs\Python\Python310\;
C:\Users\bruno\AppData\Local\Microsoft\WindowsApps;
C:\Users\bruno\AppData\Local\Programs\Microsoft VS Code\bin

Ugh...

[davidhewitt]

Do any of the first four entries or the working directory contain a "standalone" cargo which would cause the error?

EDIT: I guess C:\Users\bruno\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin ?

[davidhewitt]

So I guess the conclusion is that rustup's own tooling (?) is adding a PATH entry which means the future +nightly argument fails. I think in that case this patch makes sense 👍