rustup icon indicating copy to clipboard operation
rustup copied to clipboard

Homebrew conflicts with rustup (detect and warn about it?)

Open kornelski opened this issue 8 years ago • 5 comments

On macOS if you install anything with Homebrew that has Rust as a dependency (including any program that has to be built from Rust source), Homebrew will install Rust system-wide and it will take precedence over rustup.

I've ran into this — it looked like if rustup default command didn't work properly. I took me a while to realize that binaries in /usr/local/bin are not from rustup.

Homebrew dislikes using any binaries and update mechanisms they don't control (including rustup), so I think it's up to Rustup to improve this situation.

As a solution I suggest emitting a warning when rustup default command is used if the PATH contains both Rustup rustc and non-Rustup rustc, and non-Rustup rustc is first. That will catch this error, but won't get in the way of using Rustup without the PATH modified for Rustup.

kornelski avatar Aug 14 '17 20:08 kornelski

A quick fix is brew uninstall rust or brew unlink rust. rustup and rustup-init formulas are mutually-exclusive, and should mutually conflicts or whatever with each other. The latter seems to be a brew package of rustup. Files issues about Homebrew there, because rustup properly detects an existing rust and exits.

skull-squadron avatar Aug 23 '17 07:08 skull-squadron

To clarify, the situation I'm talking about has nothing to do with conflicts of Homebrew's packages.

Consider this scenario:

  1. Install rustup and use rustc from rustup (there's no Homebrew rustc, no conflict)
  2. Install rustc from Homebrew (Homebrew doesn't care rustup is there, and does not report any problem)
  3. Try to use rustup default to change rustc (doesn't appear to work)

I would like 3. to warn that it's been affected by another rustc in PATH, and it no longer works as usual.

While I mention Homebrew specifically, the problem is not unique to Homebrew. Identical problem can happen when you install another copy of rustc from any package manager.

kornelski avatar Oct 21 '17 12:10 kornelski

@rustbot label: +O-macos

workingjubilee avatar Apr 29 '21 20:04 workingjubilee

Mitigated by https://github.com/Homebrew/homebrew-core/pull/177983 if you're using a brew-managed rustup installation.

Please note that now you need to add $(brew --prefix rustup)/bin to PATH manually to reach to the rustup-installed toolchain. Additionally, you might run brew unlink rust to make sure you won't accidentally trigger the brew-managed rust toolchain.

I'll adjust the user guide shortly.

(Sorry, that was a misclick below...)

rami3l avatar Jul 23 '24 12:07 rami3l

This is still breaking Rust for users. The existing mitigations don't help — when a brew user installs some rust-dependent package, which brew decides to build from source, they are going to get brew's rust package, and not rustup, and it's the rust package that causes the issues.

kornelski avatar Jul 23 '24 18:07 kornelski

I second the concern on this issue, it yields unintuitive situations/errors such as:

(...)
error[E0463]: can't find crate for `core`
  |
  = note: the `riscv32imac-unknown-none-elf` target may not be installed
  = help: consider downloading the target with `rustup target add riscv32imac-unknown-none-elf`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `critical-section` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `cfg-if` (lib) due to 1 previous error

In an otherwise perfectly compilable project... the fix was running brew uninstall rust and everything started working again.

brainstorm avatar Apr 04 '25 00:04 brainstorm

This is still breaking Rust for users. The existing mitigations don't help — when a brew user installs some rust-dependent package, which brew decides to build from source, they are going to get brew's rust package, and not rustup, and it's the rust package that causes the issues.

@kornelski After another look I believe we should really add a caveat to Homebrew instead of doing the check here, because 1) that will impose some unnecessary penalty to our already far-from-ideal startup time; 2) I imagine many have issued brew install rust indirectly as, for example, a build dependency.

I have contributed to homebrew-core before, so I can offer to do that.

@brainstorm Just another remark: you don't need to brew uninstall rust; brew unlink rust keeps the build dependency intact without interfering with the existing installations.

rami3l avatar Apr 05 '25 02:04 rami3l

I'm closing this issue as completed since I have successfully made 3 PRs adding extra pointers in both homebrew-core and our docs:

  • https://github.com/Homebrew/homebrew-core/pull/218316
  • https://github.com/Homebrew/homebrew-core/pull/220021
  • https://github.com/rust-lang/rustup/pull/4283

Specifically, when you issue brew install rust either directly or indirectly, you should receive a clear warning from now on with a link to our docs.

Admittedly, homebrew-core only accepts instructions WRT resolving conflicts between rust and rustup specifically installed from them, which is perfectly reasonable from their standpoint, but in the link that the caveats point to, I have also included a particular example in our docs about a conflict between homebrew-installed Rust and rustup fetched from https://rustup.rs. As such, I believe I have resolved this issue on a best-effort basis. Any suggestions on improving our docs is welcomed, but that belongs to another issue/PR.

rami3l avatar Apr 15 '25 06:04 rami3l