26 ms·

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 don

by tacker2000 11mo 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...

anamexis 11mo ago
What is the pro vs consumer distinction here? What consumers use homebrew?
- tacker2000 11mo ago
  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 11mo ago
    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.
    - tacker2000 11mo ago
      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 11mo ago
      so don't use brew at all? Great, what else should we not use?
      - simonw 11mo ago
        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_ 11mo ago
        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 11mo ago
        [dead]
    - potamic 11mo ago
      When all you have is a hammer, everything looks like a nail.
  - supriyo-biswas 11mo ago
    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 11mo ago
      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!
      - richwater 11mo ago
        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.
        tacker2000 11mo ago
        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.
        amake 11mo ago
        “Pro” users are using containers, venvs, version managers (nvm, rvm, etc.). They definitely aren’t installing project-specific stuff directly to the system.
ryandrake 11mo ago
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.
- cweagans 11mo ago
  > I'd like to see a third option Nix, perhaps?
  - pxc 11mo ago
    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 11mo ago
    Make Fink modern. ;) (Part /s, part not)
- asdff 11mo ago
  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.
- dirkt 11mo ago
  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?)
inopinatus 11mo ago
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 11mo ago
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.
wvenable 11mo 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. No different than Apple themselves!
vr46 11mo ago
I know, is there any point in calling it Homebrew anymore when it's like an extension of the App Store?
jen20 11mo ago
> 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.

anamexis 11mo ago

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

tacker2000 11mo ago
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 11mo ago
  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.
  - tacker2000 11mo ago
    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 11mo ago
    so don't use brew at all? Great, what else should we not use?
    - simonw 11mo ago
      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_ 11mo ago
        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 11mo ago
        [dead]
  - potamic 11mo ago
    When all you have is a hammer, everything looks like a nail.
- supriyo-biswas 11mo ago
  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 11mo ago
    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!
    - richwater 11mo ago
      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.
      - tacker2000 11mo ago
        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.
        amake 11mo ago
        “Pro” users are using containers, venvs, version managers (nvm, rvm, etc.). They definitely aren’t installing project-specific stuff directly to the system.

ryandrake 11mo ago

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.

cweagans 11mo ago
> I'd like to see a third option Nix, perhaps?
- pxc 11mo ago
  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 11mo ago
  Make Fink modern. ;) (Part /s, part not)
asdff 11mo ago
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.
dirkt 11mo ago
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?)

inopinatus 11mo ago

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 11mo ago

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.

wvenable 11mo 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. No different than Apple themselves!

vr46 11mo ago

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

jen20 11mo ago

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