Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call the right cargo binary #2558

Merged
merged 1 commit into from Aug 25, 2022
Merged

Call the right cargo binary #2558

merged 1 commit into from Aug 25, 2022

Conversation

mejrs
Copy link
Member

@mejrs mejrs commented Aug 16, 2022

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

error: no such subcommand: `+nightly`

@messense
Copy link
Member

messense commented Aug 17, 2022

+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
Copy link
Member Author

mejrs commented Aug 17, 2022

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

mejrs commented Aug 22, 2022

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
Copy link
Member

davidhewitt commented Aug 23, 2022

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
Copy link
Member

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 👍

@davidhewitt davidhewitt merged commit f927cdb into PyO3:main Aug 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants