tacker2000 10 hours ago

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...

▲ wvenable 25 minutes ago | parent | next [-]

> 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!

▲ inopinatus 6 hours ago | parent | prev | next [-]

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.

▲ wpm 2 hours ago | parent | prev | next [-]

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.

▲ ryandrake 9 hours ago | parent | prev | next [-]

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.

▲

dirkt an hour ago | parent | next [-]

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?)

▲

nake89 an hour ago | parent | prev | next [-]

"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.

▲

cweagans 9 hours ago | parent | prev | next [-]

> I'd like to see a third option

Nix, perhaps?

	▲	pxc 9 hours ago \| parent \| next [-]
		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.
	▲	Klonoar 3 hours ago \| parent \| prev [-]
		Make Fink modern. ;) (Part /s, part not)

▲

asdff 8 hours ago | parent | prev [-]

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.

▲ anamexis 10 hours ago | parent | prev [-]

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

▲

tacker2000 10 hours ago | parent [-]

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...

▲

simonw 9 hours ago | parent | next [-]

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.

▲

potamic 2 hours ago | parent | next [-]

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

▲

tacker2000 9 hours ago | parent | prev | next [-]

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.

▲

knowitnone3 8 hours ago | parent | prev [-]

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

▲

simonw 8 hours ago | parent [-]

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.

▲

tom_ 7 hours ago | parent [-]

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.

	▲	tort995 26 minutes ago \| parent [-]
		[dead]

▲

supriyo-biswas 4 hours ago | parent | prev [-]

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.

	▲	tacker2000 13 minutes ago \| parent [-]
		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!