Skip to content

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

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

Closed
kornelski opened this issue Aug 14, 2017 · 8 comments · Fixed by Homebrew/homebrew-core#218316
Closed
Labels
O-macos Mac OS related
Milestone

Comments

@kornelski
Copy link
Contributor

kornelski commented Aug 14, 2017

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.

@skull-squadron
Copy link

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.

@kornelski kornelski reopened this Oct 21, 2017
@kornelski
Copy link
Contributor Author

kornelski commented Oct 21, 2017

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.

@workingjubilee
Copy link
Member

@rustbot label: +O-macos

@rami3l
Copy link
Member

rami3l commented Jul 23, 2024

Mitigated by Homebrew/homebrew-core#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...)

@kornelski
Copy link
Contributor Author

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.

ivanzemskiy added a commit to ivanzemskiy/brew-deps-tree that referenced this issue Dec 30, 2024
@brainstorm
Copy link

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.

@rami3l
Copy link
Member

rami3l commented Apr 5, 2025

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

rami3l commented Apr 15, 2025

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

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 rami3l closed this as completed Apr 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-macos Mac OS related
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants