Binary named `rust-analyzer` added to cargo bin path even when component is not added

praveenperera commented 4 months ago

Verification

[X] I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
[X] I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

Rustup keeps adding a binary named rust-analyzer to the .cargo/bin folder. But I didn't add it because I want homebrew to manage rust-analyzer version, because I want the latest version. But since there is a rust-analyer in my path at ~/.cargo/bin/rust-analyzer my editor tries to use it.

Opening it i get a message

error: Unknown binary 'rust-analyzer' in official toolchain 'stable-aarch64-apple-darwin'.
To install, run `rustup component add rust-analyzer`

This is very annoying because I keep having to delete this dummy binary everytime i run rustup so my editor can find the actual binary. Is there any reason to create these dummy binaries? Can I disable this?

Steps

Install rustup with with minimal

Possible Solution(s)

No response

Notes

No response

Rustup version

rustup 1.27.1 (54dd3d00f 2024-04-24)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.78.0 (9b00956e5 2024-04-29)`

Installed toolchains

Default host: aarch64-apple-darwin
rustup home:  /Users/praveen/.rustup

stable-aarch64-apple-darwin (default)
rustc 1.78.0 (9b00956e5 2024-04-29)

OS version

MacOS Version 14.5 (23F79)

praveenperera commented 4 months ago

I can make this less annoying by putting homebrew path before the cargo path, but I don't understand why its installing these dummy binaries into the PATH in the first place

rami3l commented 4 months ago

@praveenperera Thanks for filing this issue!

Is there any reason to create these dummy binaries?

Yes, since rustup would want to add a shim for rust-analyzer.

Can i disable this?

AFAIK you can't, unfortunately. However this point has been pointed out in the original PR by @ehuss:

This adds rust-analyzer as a proxy. ... There is some risk this could cause disruption if a user is relying on having rust-analyzer in their PATH and this gets in the way. I suspect (hope?) that isn't too common. We may want to consider holding off on releasing this until after the 1.64 release. https://github.com/rust-lang/rustup/pull/3022#issue-1296235700

If you are a VSCode user, it would be okay if you just use the plugin-bundled version of rust-analyzer, as it's guaranteed to be up-to-date. If you are not, well, to be frank I think this is a point to be improved, since I also use a non-Rustup distribution of rust-analyzer (from Neovim's mason to be precise).

@rbtcollins Do you think it'll be fine if we only add shims for installed components (or DUP_TOOLS, to be more specific)? Will that disrupt our current stability guarantees/business logic too much?

praveenperera commented 4 months ago

Thanks, ya I meant is there a reason that the dummy binary needs to added when the component is not added?

I guess the current method gives a message that shows people how to install it using rustup, but I don't know if thats a worthwhile tradeoff. Unless theres other benefits I'm missing?

rami3l commented 4 months ago

@praveenperera Looking at

https://github.com/rust-lang/rustup/blob/454e8dc1bf31f20821cc8ac3228ea1f35b23d072/src/cli/self_update.rs#L804-L832

... a possible workaround would be manually adding a symlink under ~/.cargo/bin/ pointing to wherever your actual rust-analyzer installation would be.

djc commented 4 months ago

@rbtcollins Do you think it'll be fine if we only add shims for installed components (or DUP_TOOLS, to be more specific)? Will that disrupt our current stability guarantees/business logic too much?

Don't we decide which components to install on a per-toolchain basis? If that is the case, it would be tricky to decide which shims to install.

rami3l commented 4 months ago

@rbtcollins Do you think it'll be fine if we only add shims for installed components (or DUP_TOOLS, to be more specific)? Will that disrupt our current stability guarantees/business logic too much?

Don't we decide which components to install on a per-toolchain basis? If that is the case, it would be tricky to decide which shims to install.

@djc Indeed, although this is a qualitative description.

I'm not sure about this idea security-wise, but I was thinking about implementing a rust-analyzer shim that, right before throwing the aforementioned "binary not found" error, turns into a "transparent" shim and tries to call rust-analyzer once more but without searching ~/.cargo/bin/. This behavior is per-toolchain because with a toolchain that has rust-analyzer installed, the error would't have been thrown in the first place.

If you think that sounds too disruptive (or even unrealistic), another solution could be confirming and solidifying the hack in https://github.com/rust-lang/rustup/issues/3846#issuecomment-2136372047. Maybe by adding a help message or something.

djc commented 4 months ago

I'm not sure about this idea security-wise, but I was thinking about implementing a rust-analyzer shim that, right before throwing the aforementioned "binary not found" error, turns into a "transparent" shim and tries to call rust-analyzer once more but without searching ~/.cargo/bin/. This behavior is per-toolchain because with a toolchain that has rust-analyzer installed, the error would't have been thrown in the first place.

Sounds reasonable to me... Security-wise it seems okay to me because we're merely relying on the PATH that the user has set anyway (and so implicitly trusts).

rbtcollins commented 4 months ago

Fundamentally this is out of our hands. Either the rust project is shipping rust analyser as part of versioned releases, in which case the shim is needed to permit running the command. Or it is not, in which case we can remove the shim.

I think it is reasonable for things like editor plugins which choose to manage a single version of rust analyser to +not+ depend on PATH to locate it, since there are many such editor plugins, as well as single version distributions like homebrew.

rbtcollins commented 4 months ago

I'm not sure if the bug reported here is 'i get an error', or, 'the wrong version runs': consider that we might teach this one proxy to fall back to path, but then the bug changes to be 'wrong version because I had the component installed'.

I suggest finding out the plans of rust analyser.

If the situation is transitory , I recommend doing nothing.. Users can put their own bin before the cargo bin anyway.

If we add special case complexity, it affects our users as it becomes one more thing they have to learn about when the system behaves in a surprising manner.

KorigamiK commented 1 month ago

error: Unknown binary 'rust-analyzer' in official toolchain 'stable-aarch64-apple-darwin'. To install, run rustup component add rust-analyzer

I can confirm this issue on linux. However I don't seem to get the suggestion to add the component.

Unknown binary 'rust-analyzer' in official toolchain '1.80-x86_64-unknown-linux-gnu'

rust-lang / rustup