Hacker News Reader

Comment by tacker2000 | Hacker News Reader

tacker2000

Homebrew is not really pro in any way: they force updates, deprecate old software that is still widely in use, the maintainers are always very combative and dont allow any discussions or other opinions.

In the end it's a package manager for consumers that hand holds you and is not really useful in a pro context.

I've been meaning to jump to macports anyway, maybe ill do it now...

View on HN

So-called “homebrew” has only ever grudgingly provided the barest minimum of hooks to locally build your own variants of their packages, and compares most unfavourably to, say, maintaining your own easily-rebased fork of a BSD-style ports tree. Don’t even get me started on its janky dependency resolution, versioning, “services”, and lifecycle.

The hostility and self-righteousness from the maintainers in the thread linked above just adds to the general shittiness of using it at all, and yet somehow it seems to be the lowest common denominator choice for far too many teams I’ve worked with, I suppose by sheer inertia.

I started on Macports 20 years ago, switched to homebrew because it was the new thing, and this year switched back to Macports on a brand new M4 mini, after having this gnawing feeling that I should have never switched after installing Macports on a PowerBook G4 running Tiger and building something relatively modern from source without any problems.

As someone who migrated from macports to Homebrew, I'd like to see a third option (or maybe re-investigate macports again to see what's changed recently).

Homebrew's insistence on leaving OSes behind that they deem to be "too old" is becoming a problem as the years click by. One of the reasons to use third party software and a third party package manager is to avoid Apple's own insistence on abandoning old OSes. Homebrew following their example is very disappointing.

EDIT: From the linked issue:

    "Intel support is coming to an end from both Apple and Homebrew."

Deeply, deeply disappointing. I know Open Source doesn't owe us anything, but this seems like a terrible turn for what was once great software.

> I'd like to see a third option

Nix, perhaps?

Also Pkgsrc

if you're good with tools that don't support global installs there are also Spack, Mise, and pkgx

none of those are quite suitable for managing macOS app bundles, though.

Make Fink modern. ;)

(Part /s, part not)

Honestly conda does a lot of heavy lifting for me. I know people have strong feelings about it on here but it works great for my purposes.

I actually migrated from Homebrew to Macports after ending up in dependency hell in Homebrew with Postgresql + Postgis, and not being able to fix this properly even with my own brew recipes.

So for now that works a lot better in Macports. The portfile stuff needed some digging to understand, but that's doable.

Not sure what made you move from Macports to Homebrew. (Should I worry?)

"Homebrew's insistence on leaving OSes behind that they deem to be "too old" is becoming a problem as the years click by"

Indeed! I have a VERY usable Macbook Pro from 2015. Even with the newest version supported macOS version (11) Big Sur (which is still quite modern) it doesn't have any binaries for apps, which means it has to compile every single app and dependency.

I managed to update to macOS 14 (with the help of OpenCore Legacy Patcher).

But this just buys me one year to use Homebrew. Next year they will retire macOS 14.

And my machine is still very usable, but it will become junk from a developer perspective unless I have homebrew (or something similar).

It annoys me because I think this problem is fixable. Either community repos or more donations to homebrew to compile apps for older macs.

How much are you willing to donate before concluding it's more efficient to just buy a new MacBook? Even the cheapest models now are faster, more energy efficient and more secure. You don't have to throw the old one away if you can find a use case for running old software but I don't think there are many people running 'power user / developer' like tasks on old hardware, especially if their jobs depend on it.

I went through the same experience with an old macbook. Switching to macports solved that problem.

It's too bad that homebrew adopted the "Apple Attitude" around dealing with legacy OS versions. I don't recall ever seeing a message while working in Linux saying "Oh, you're using an OLD version of Linux, that's unsupported! You're a Tier-3 Loser and we don't guarantee this is going to work!"

Even developer tools on Windows tend to be fairly graceful about you running Windows 7 or whatever.

Somehow Apple and their entire ecosystem has adopted this "Latest Version Or GTFO" attitude towards users and developers.

Nix is sort of that third option, though I really wish there was a well-documented way to use it on macOS as purely a binary/source package manager. A lot of stuff I read online goes into setting up nix-darwin to manage desktop settings and etc. and I just don't need or want that.

That being said, if you haven't used MacPorts in years, I'd say it's worth the jump. I recall moving from MacPorts in the first place because Homebrew was faster and allowed for customising packages.

When I switched back to MacPorts again, it was because Homebrew had become slow and no longer allowed package customisation. Now, MacPorts is much faster and has the variants system for package customisation.

Thank you for this helpful information. It might be worth a try. I initially moved to brew because it was "new", because I liked the command line interface, and because it seemed more "segregated" from the rest of the OS's files (/usr/local/Cellar and so on). But it's increasingly aggressive messages reminding me I am a second-class (or third-class) citizen due to the age of my OS is really off-putting.

I know, is there any point in calling it Homebrew anymore when it's like an extension of the App Store?

What is the pro vs consumer distinction here? What consumers use homebrew?

im talking about developers for example, that may need specific/old versions of php or node or whatever, which then get deprecated and uninstallable via brew as soon as they officially reach EOL. Or once installed, get forcefully and inadvertently updated by brew.

On the other side is some consumer who uses brew to install youtube downloader and doesnt care about versions/upgrades, etc...

If you are a developer who needs a specific old version of PHP or Node or whatever and you're not using Docker then I have great news for you on how you can solve your problem.

yes, docker is a great solution nowadays for this problem, but it wasnt always like that. In PHP land there is a tool called Laravel Valet, which relies heavily on homebrew and lets you switch PHP versions on the fly directly your system. I just remember how much of a pain it was to set up because of homebrew's unnecessary restrictions and deprecations. But once done it worked quite well.

so don't use brew at all? Great, what else should we not use?

I personally use and enjoy Homebrew for most of my development tasks. The thing I would not use it for is to exactly simulate a specific combination of tool versions.

Yes. The package manager's job is to give you some sensible version of some useful common standardized thing(s) you want to use. There might well be some legacy/current/edge options, but overall you are putting your trust in their judgement and assuming that they'll do something at least vaguely sensible.

If you want something specific than that: the package manager cannot help you here. This is no longer some random thing that you just use; it's one of your product's honest-to-goodness dependencies. You can't outsource this any more. You need to make your own arrangements to ensure that the specific version required is in use.

When all you have is a hammer, everything looks like a nail.

brew install php@X.Y doesn’t work for you?

Although I should say that I haven’t tried to go back many major versions, I wonder if they provide 7.x for example.

It works until PHP officially EOLs the version. Then brew stops supporting it and you have to install some finicky 3rd party taps/repos to get the older versions. A huge pain...

In the real world there are still apps running PHP 7.4 and even older!

I seriously can't accept this as valid criticism.

Homebrew not allowing users to install EOL versions of software with no security patches or updates is a _good_ idea. Just because a fraction of a tiny minority needs some ancient version of PHP doesn't make it a good idea.

yea, that's why it's not "pro" grade, and that's my point.

"pro" users need EOL version support because sometimes some client still didn't want to update his age old web app the newest node or python or whatever. sometimes it's not up to the dev himself, and he needs to make money either way.

so in the end brew makes decisions for the most common denominator, and that will be the user that uses it to install youtube-dl and nothing more.

“Pro” users are using containers, venvs, version managers (nvm, rvm, etc.). They definitely aren’t installing project-specific stuff directly to the system.

> is not really useful in a pro context.

Huh, I guess I didn't use it in a "pro" context for 14 years then? Must have imagined that.

> Homebrew is not really pro in any way: they force updates, deprecate old software that is still widely in use, the maintainers are always very combative and dont allow any discussions or other opinions.

No different than Apple themselves!

Reply on news.ycombinator.com