Brew is overly eager to replace pkg-config

And that’s incredibly annoying. Every time I work on a new computer it eventually happens. Same for python really, I remember having to unlink python several times a day at some point because it kept relinking a broke binary as a dependency of nvim.
Could there be some kind of “This is homebrew’s btw” notice when some of its binaries are executed? Or just renaming it to brew_pkg-config by default?
It’s obnoxious in python’s and pkg’s specific cased because:
-pkg-config manages system dev libraries. Cue to spending hours trying to find out why make is failing because the only times I ever am reminded pkg-config exists is when this issue pops up, like clockwork, in fresh installs. And brew just doesn’t have the width of libraries available to justify using it instead of the system’s.
-Python also is a program that tends to have a ton of libraries installed systemside, which brew’s ignores. I imagine to avoid nightmarish dll-hell scenarios.

I hate to say this when reporting issues about software, but I can’t think of any clean solution to the issue as much as I dislike it. Renaming the binary would break scripts, adding that notice I mentioned would also break scripts that parse said output. Maybe sending it to STDERR or some other stream?

Please more courteous when writing; you agreed to do so as part of our Code of Conduct.

On Linux, Homebrew aims to be as much of a self-contained installation as possible, so mixing it with system packages understandably can cause problems. If you need a mix of brewed and system packages, you may find it more useful to remove Homebrew from your PATH, and instead only include specific formulae. For example, if you only need a newer version of wget, add $(brew --prefix wget)/bin to your PATH.

Ye, I imagined that was why. Not exactly dll hell, but it’s of the same system-breaking flavor.

That does seem appealing.

But the reason why I made this thread is I can’t help seeing this as a huge issue at a new or occassional user level. Pkg-config is replaced silently as a dependency when building a non-bottled package (I think silently? Or it happens in the middle of a long series of scripts which the user may just alt tab out of) and then you only find out what’s breaking make when you specifically know what too looking for-- the first time I ran into this it took me some time to even find out pkg-config existed in the first place. It’s a very quiet-but-always-there program.
It’s not a very googleable error either- “My system doesn’t have this library” will put a shipload of threads that aren’t relevant to the issue on your face. And I realize brew is a tool used chiefly by programmers, but it provides plenty of software not specific to them.

Sorry if I was too strongly worded, I tend to be too forward when discussing UX.

Setting PKG_CONFIG_PATH according to user requirements is of course another way to get the desired results, but thinking out loud about a more user-friendly solution…

How about making pkgconfig keg-only, and hardcoding $(brew --prefix pkgconfig)/bin in the superenv PATH? That way, Homebrew builds remain self-contained, non-Homebrew builds continue to default to system libraries, and users augment their PATH with pkgconfig's bin only when they want to link against Homebrew libraries.

Call it the "PATH of Least Surprise"? :grinning:

Homebrew on Linux intentionally has no keg-only packages. Homebrew on Linux is meant to be able to replace (nearly) all system-provided packages, to provide a consistent experience across multiple distributions of Linux, without requiring administrator access to the system. If you want to sometimes be using Homebrew’s executables, and sometimes using the system’s executables, I’d recommend omitting Homebrew’s bin directory from your default PATH. You can then either…

  1. Add specific packages to your PATH as suggested by @jonchang
  2. Symlink specific executables into your ~/bin in your default PATH
  3. Create a shell script named linuxbrew in your default PATH that adds ~/.linuxbrew/bin to your PATH, so that you can run source linuxbrew in an interactive shell to intentionally switch from using system-provided tools to using Homebrew-provided tools. Note this solution is similar to how Conda’s source activate works. I personally like to name this script me, so that you type source me. :grin: or perhaps ry for source ry:laughing:

Note that mixing and matching packages from the host and Homebrew is inherently complex, and no one solution can meet all users’ preferences.

1 Like