I was so glad to remove all that (and to a lesser extent, trying to maintain both Homebrew package names and pacman/AUR names for everything, which obviously sometimes differ or need a different thing anyway) when I started using a Linux machine for work (already did personally). That might change again unfortunately; I'm hoping some day Nix or something like it is a cross-platform solution, but I don't think it's there yet. Discovering the `defaults` options (or worse: what you're setting that no longer does anything) is a nightmare.
I'm secretly hoping for a makepkg / pacman-based replacement to homebrew, to have the same set of commands and package naming conventions across mac / win / linux
I'm using Nix now on my macOS installs, so I might not be totally correct the current situation. But yeah, I believe most of those sorts of issues have gone away with the new prefix.
There's still some weird annoyances for me, though. For example, it's still intended for single-user mode only. The best solution I came up with was to create a separate user for Homebrew and then basically alias `brew` to `sudo -H -u homebrew brew`.
And generally, if you attempt to use a non-standard prefix, such as in your home directory, packages will have to be built from source. I understand why, but it sucks because this means when you need x86-only packages via Rosetta, you're stuck with the old `/usr/bin` prefix, unless you want to and can build from source.
Also, in general, maintaining multiple prefixes/architectures is annoying too. I wish the default command allowed me to just pass `--arch amd64/arm64` or something when installing packages
To be fair, homebrew shouldn't need to change perms, it should follow common unix standards or at least fit in with OSX rather than require a hack. For years I've felt homebrew should really use either /opt/ or ~/.homebrew/ by default.
This was one of the pain points that made me move back to Linux on my devices, and I'm glad I did it. Homebrew is infuriating when you're used to real package managers.
What we need is a cross platform package manager that installs stuff in the same place and make stuff behave the same, so shell configs can be unified between OS and not have "if" all over and expect same environments.
nix is almost that, except some packages are too old but otherwise, I have it running identically on macOS and Linux.
Homebrew puts stuff in some weird location that is /home/linuxbrew/.linuxbrew/ on Linux and that alone puts me off and it breaks if I change that location. No idea why they don't just use a path like /opt/homebrew/ for both OS and be done with it.
Can you disable all of its cutesy names? Bottles for binaries, cellar for package path, taps for 3rd party repos, recipe (or formula? I forget) for build scripts, cask for a REPL... I honestly got a bit confused at first by what all of these things meant.
I used to recommend Homebrew but stopped some time ago (v2, perhaps?) when they hard-removed all build customization/options in order to make it easier to develop bottles and close out GitHub issues (on their end) while severely restricting what users could do, taking away a lot of power and freedom that was previously available. Much more inline with the Apple line of thinking, but that’s kind of the reason people wanted a *nix-esque package manager, no?
Been using homebrew for many years, thanks. Although, I think the permissions model is broken. I wish Homebrew supported multiple accounts. On my macbook m1, all accounts point to /opt/homebrew and it is a giant ball of mess. Modifying the prefix to ~/homebrew leads to other packages that hard code the path such as pyenv.
I think we need a new package manager since its not the fault of homebrew that many packages have hardcoded stuff in there.
> "homebrew for linux" type package manager that could safely manage software without conflicting with OS packages.
As someone who uses Homebrew for Linux, I can say that "without conflicting with OS packages" cuts both ways: fine, I get more modern stuff than apt could imagine, but having to monkey with the LD_LIBRARY_PATH or -Wl,-rpath over and over gets old real fast. I have no idea why they tried to be so cute putting things in a stupid directory (/home/linuxbrew/.linuxbrew) instead of /usr/local like they did with Homebrew for Mac (err, not the arm64 version, where they went back to /opt/homebrew for whoknowswhy)
You know, for all the nerding out about how package managers do their work and how “correct” they are, they all still pale in comparison to how easy and intuitive homebrew is to use.
I’m running Linux and pacman/yay are great but if something is screwed up I miss being able to run brew doctor to figure out what’s wrong or add a tap for some weird thing here or there.
I know I’ll get crucified for saying it but usability counts for a lot and apt, dpkg, yum, dnf, and yes, even nix suck. All the correctness and perfection don’t matter if nobody uses or wants to use your software.
While i kinda wish mac users would stop trying to give us homebrew, im open minded.
Im curious how this works with linux package managers that already exist, does this work like how the aur and aur helpers layer over pacman but maintain compatibility with the community repos?
Is using prefix really all that annoying? I run Ubuntu as well as OS X, and I like to keep my compiled software segregated from my package installed software. This means I "prefix everything". I mean really, using --prefix is minor in contrast to some of the other difficulties encountered when compiling software.
Homebrew has advanced the state of package management on OS X significantly. Anyone considering a Mac laptop should look in to it to see if the packages you need are there.
On the advice of numerous HN threads, I switched from Homebrew to Nix, and gave it a 6 month shot. Nix was great at first: simple, fast, elegant. However, I quickly realized that the simplicity was a facade that even a casual user would eventually be forced to remove. And what you find behind the facade gets really, complex really quickly.
What I appreciate about Homebrew is that in years of using it, I have never felt the need to dive deeply into its inner workings. For the most part, it just works. I can access the utilities I need to do my work and reliably keep them updated. Homebrew has its problems for sure, but the tooling has improved immensely over the recent years. So thank you for your work!!!
Also side note, I just recently discovered the brew bundle command's --global flag. It basically let's you use a declarative format globally installed taps, formula, casks, and vscode extensions. I can add the .Brewfile to my dotfiles repo to sync across machines. Though, it's not really what the bundle command is meant for, it sure beats manually copying down and installing the list of formula.
I use Homebrew, but you have to prefix most GNU utilities by 'g', unless you are willing to 'override' Darwin's utilities by having the GNU counterparts earlier in the path.
Besides that, Homebrew does not solve the fact that for a lot of Apple-specific utilities, subsystems, and daemons there are no man pages.
(I do agree that Homebrew is a great project, have been using it pretty much since its inception.)
So strange, as i'm the polar opposite. I vastly prefer having everything update at once and be able to check versions, etc. I use homebrew and chocolately when I'm on macOS or Windows respectively to get that experience back.
I can understand trying to resolve dependencies can be a royal pain, espescially trying to find the distro's specific naming conventions, like libpq-dev vs postgresql-libs
I've stayed away from Homebrew because of its insistence on taking over /usr/local. I understand the reasoning, but I use /usr/local for my own installs and Homebrew doesn't play nicely in that kind of mixed environment. I would use it if it defaulted to /opt/homebrew or something similar.
I'm looking forward to this new package manager alternative.
Where does your homebrew live? I have a few different users on my mac that I want to all share resources so I've kept it in /usr/local (also the "easiest" because it was the default).
TBH, things like this make me really mis debian. It's really nice when your package manager is a first class citizen (and geared towards software development rather than consumption).
reply