rustup run also searches PATH

[jyn514]

Problem

; rustup run 1.69 whoami
jyn

This seems ... undesirable. In particular, it means that rustup which and rustup run differ in behavior:

; rustup which whoami
error: not a file: '/Users/jyn/.local/lib/rustup/toolchains/1.69-aarch64-apple-darwin/bin/whoami'

As far as I can tell, the only difference is that rustup run sets RUSTUP_TOOLCHAIN and DYLD_FALLBACK_LIBRARY_PATH:

; rustup run nightly python3 -c $'import os \nfor k,v in os.environ.items(): print(k, v)'  | sort -u | diff - <(python3 -c $'import os \nfor k,v in os.environ.items(): print(k, v)' | sort -u)
8d7
< DYLD_FALLBACK_LIBRARY_PATH /Users/jyn/.local/lib/rustup/toolchains/nightly-aarch64-apple-darwin/lib:/Users/jyn/lib:/usr/local/lib:/usr/lib
29,30d27
< RUSTUP_TOOLCHAIN nightly-aarch64-apple-darwin
< RUST_RECURSION_COUNT 1
49c46
< _ /Users/jyn/.local/lib/cargo/bin/rustup
---
> _ /Applications/Xcode.app/Contents/Developer/usr/bin/python3

my original use case, although it's pretty complicated

i am writing a new rustc_driver tool that goes in the sysroot. i want to be able to run it as cargo +nightly foo instead of PATH=$PATH:$(rustc +nightly --print sysroot)/bin cargo +nightly foo. to that end, i've put a shell script in ~/.cargo/bin/cargo-foo that emulates a rustup proxy:

#!/bin/sh
me=$(basename $0)
exec rustup run "$RUSTUP_TOOLCHAIN" $me "$@"

This works fine if the tool is actually present in the sysroot. However, if it's not present, rustup falls back to path and re-executes this same script, eventually leading to a recursion error that it's nested too deeply. I would like to instead give a hard error. Today, i have to workaround rustup's behavior with more calls:

# Make sure this is actually installed for the given toolchain. `rustup run` falls back to PATH,
# which will recursively invoke this script; that's not what we want.
if ! rustup which $me --toolchain $RUSTUP_TOOLCHAIN 2>/dev/null; then
    printf "\033[31;1merror:\033[0m '$me' is not installed for the toolchain '$RUSTUP_TOOLCHAIN'\n"
    exit 1
fi

it would be nice to be able to avoid that.

Steps

rustup run 1.69 whoami (or any installed toolchain)

Possible Solution(s)

• Break hard; only look in toolchains/1.69/bin
• Add a feature flag to remove the PATH lookup
• Document the difference somewhere

Notes

No response

Rustup version

rustup 1.26.0 (5af9b9484 2023-04-05)

Installed toolchains

Default host: aarch64-apple-darwin
rustup home:  /Users/jyn/.local/lib/rustup

installed toolchains
--------------------

nightly-2022-12-07-aarch64-apple-darwin
nightly-2023-03-14-aarch64-apple-darwin
nightly-2023-04-12-aarch64-apple-darwin
nightly-aarch64-apple-darwin (default)
1.60-aarch64-apple-darwin
1.64-aarch64-apple-darwin
1.65-aarch64-apple-darwin
1.68-aarch64-apple-darwin
1.69-aarch64-apple-darwin
stage1
stage2
1.60.0-aarch64-apple-darwin

installed targets for active toolchain
--------------------------------------

aarch64-apple-darwin
aarch64-unknown-linux-gnu

active toolchain
----------------

1.69-aarch64-apple-darwin (overridden by '/Users/jyn/src/redacted/rust-toolchain.toml')
rustc 1.69.0 (84c898d65 2023-04-16)

[rbtcollins]

Offhand I think there is another subtlety; rustup which doesn't do cargo fallbacks. rustup run does. Its not clear whether which should know about that fallback logic or not.

[jyn514]

we cleared it up - yes, you're exactly right:

; rustup which cargo --toolchain stage1
error: not a file: '/Users/jyn/.local/lib/rustup/toolchains/stage1/bin/cargo'
; rustup run stage1 cargo --version      
cargo 1.70.0-nightly (0e474cfd7 2023-03-31)

[jyn514]

Offhand I think there is another subtlety; rustup which doesn't do cargo fallbacks. rustup run does. Its not clear whether which should know about that fallback logic or not.

I would expect which to know about the fallback; ideally which would tell which 🥁 process rustup run would execute so I don't have to paper over cracks between the two.