[peteretep]

Contrarian view here: brew fucking sucks. It’s the worst package manager I’ve used for doing random unwanted updates at odd times. Someone else would have filled the void if homebrew hadn’t shown up, and it would hopefully have been better. I hate that brew is good enough that it’s got some kind of local maximum such that there’s no replacement forthcoming. There, I said it.

[woodruffw]

Homebrew maintainer here: I'm sorry that we don't meet your expectations.

Two things for your consideration:

1. It's uniquely visible among system package managers. When people have problems with a package in `apt` or `dnf`, they find a community or third-party repository for the package or bug the upstream directly. By contrast, Homebrew has always been visible on GitHub, does not require a special login to a bugtracker on some random domain, and thus receives direct community support volume that we need to address.

2. Homebrew is not an official system package manager. We operate at Apple's whim, which generally ranges between neutral disinterest and actively trying to remove parts of the macOS userspace that we rely on. Many of our changes over the last decade (installing our own Ruby, rolling back custom source options) can be directly traced back to changes that Apple imposes that produce disproportionately greater maintenance effort from us.

[jedbrown]

Point 2 here is huge. If Apple cared about open source or cross-platform developers, they would pay at least one full-time Homebrew developer and upgrades would be smooth. It speaks volumes that they are swimming in money and can't be bothered to make a token gesture.

[woodruffw]

> It speaks volumes that they are swimming in money and can't be bothered to make a token gesture.

I agree with a lot of the sentiment here, but I want to make one important correction: Apple has helped us. In particular, they gave us access to DTKs for the M1 and provided us with a liaison for the migration. We're very thankful for that help.

That being said, Apple is a massive company and they have their own development goals and velocity for macOS. They're not actively looking to break Homebrew, but they're also not going to halt everything for us.

[lostcolony]

Thanks for calling that out. This is totally unrelated to everything, but it's refreshing to see people giving credit -and thanks- to behemoth companies here on HN, with the proper nuance to also call out places they could have helped more (and the understanding of why they didn't). It's too easy, and common, to pile on the shortcomings. It struck me as a standout comment even in this generally polite community.

[neuronic]

Apple swims in money and can't even be bothered to implement a hassle-free way of changing your Apple ID, especially if you own more than one device and even worse if you have 'Find My' enabled on them.

More than one person just last week got stuck in a loop where the system wants credentials for your old deactivated Apple ID. The solution isn't hard but the UX flow fucking sucks.

You must manually sign out of all devices using your old ID and sign in again. Except before you can do that you have to disable Find My. With the deactivated credentials again.

It shows the OLD email and wants the old password but you have to actually enter the NEW password in the dialogue so Find My deactivates and you can sign out.

[smsm42]

Apple has always been pretty cavalier with breaking things and also full of NIH syndrome. It works for point-n-click users which don't care which hardware or software they are clicking as long as it's shiny and pointy and clicky. But if you're a developer that cares about the OS plumbing, let alone relies on parts of it, Apple is not going to do you any favors.

The thing is efforts like homebrew is basically the only thing that keeps Apple platforms as a viable developer's platform (without it it'd be intolerable, as Apple has zero official solutions for managing software not coming in pointy-clicky Appstore packaging) - and given that macs are still popular among many developers, it's a mystery why Apple corporate pays so little attention to it. It's like they sold a car without any tires and wouldn't even acknowledge the existence of tire manufacturers, let alone how vital they are for the actual users of the product.

[michaelcampbell]

> We operate at Apple's whim, which generally ranges between neutral disinterest and actively trying to remove parts of the macOS userspace that we rely on.

<sigh> I know you're not unique in this assessment or consequence, and that's truly a shame.

[Wowfunhappy]

I think that #2 might not happen as often if Homebrew better conformed to a "UNIXy" philosophy. And to Apple's philosophy, because there is a sort of mentality to how they operate, even if you can't predict exactly what they'll do.

MacPorts hasn't had as many of these issues over the years, and I suspect that's largely down to mindset. Broadly speaking, MacPorts seems to have "first, do no harm" approach to almost everything. They don't install files in directories they didn't create, and they avoid depending on systems which are out of their control.

[paultopia]

Yes. I'm really torn about brew. On the one hand, I hate to crap on the work that the maintainers have done, and it's clearly the best thing out there for macos. On the other hand, it's a terrible dictatorial piece of software that wants to command precisely how you use your computer; those same maintainers are actively hostile to users, as evidenced by the endless stream of nasty responses to issues, arbitrary changes to disable any functionality that they believe anyone has ever misused by their standards ever, etc. I pray daily that someone will fork it.

[thomaslkjeldsen]

The decisions to enable auto update, the removal of `--with-foo` options, breaking the `brew list` command and the removal of `depends_on :x11` were all mistakes, as I see it. I have read loads of issues and pull requests to understand the reasoning but have yet to find arguments that I think justifies those breaking changes.

I get it, it's all made by volunteers, but I wish there was a package manager for macOS that was focused on professional users.

I wonder if the decision process in Homebrew has relied perhaps too much on analytics data leading to the dismissal/ignorance of features used primarily by users who have disabled analytics via the HOMEBREW_NO_ANALYTICS environment flag.

[Hamuko]

>it's a terrible dictatorial piece of software that wants to command precisely how you use your computer

I've also seen examples of where Homebrew is basically dictating on how to release your software as well. There was that one case where they decided to delete the formula for mpv since mpv didn't have a recent enough of a tagged release.

https://github.com/danielbair/homebrew-core/commit/b18f104f1...

There was also an instance with mpv where Homebrew devs got pissy about mpv not supporting Lua 5.3 and mpv devs got angry at Homebrew devs for asking to break existing user scripts to appease one package manager.

[kemayo]

That one doesn't seem unreasonable. They have a "we only support tagged releases" policy. mpv moved away from tagging releases for a bit, and their latest tagged release couldn't build on current MacOS. So they switched it to the part of their system (casks) that supports downloading and installing arbitrary binaries instead.

I think it's a fair conflict, too. For a package manager, saying "just download and compile master wherever it is right now" is rough, and I can understand them not wanting to have to look at mpv's repo and pick a good commit to pin as their "release". Offloading picking a stable release point to someone else is legitimate.

[ihuman]

To add to what you said, the formula came back a week and a half later when they returned to tagging releases.

https://github.com/Homebrew/homebrew-core/commit/82a45025682...

[LiberatedLlama]

I suppose their hand was probably forced by Apple in some way, but simply offering binary downloads for mpv in particular is subpar. There are a lot of unusual options for mpv that, in my experience, don't get pulled into prebuilt binaries. For instance, last I checked, the prebuilt packages for mpv from homebrew didn't have librubberband support. LibRubberband is great, but to effectively integrate it into your workflow you need some userscripts that mpv doesn't ship with, so many users (including packagers evidently) may not see the value in it. When I was still using MacOS, I had to build mpv myself to enable it. My memory is hazy, but I think libarchive support was in a similar situation. Eventually I cut homebrew out of the picture and chose to build mpv myself, since homebrew wasn't helping at all, just getting in the way.

[personjerry]

> dictatorial piece of software

Isn't that generally the point, for Apple consumers? At HN we have a skewed sample but I imagine for a lot of users (myself included), having an easy solution with configurations set for you is exactly what they want.

[the_other]

That's what I want.

I build web apps for a living, and I used to do it by contracting. I don't have time, patience or interest for fiddly configuration. I want a mostly-good initial experience so I can get on with my work rather than mess about with my tools. I'm aware there's some gain to be had by knowing more about my tools, but the payoff isn't obvious enough to make me change my ways.

Thanks for being mostly-great, brew.

[jack_riminton]

Exactly, it’s the same reason I use Mac instead of Linux. I want to make things. I don’t want to waste time fiddling with endless verbose details I don’t need to know

Yours, A Noob

[anaerobicover]

Not for developers, no. "Normal" Apple consumers have little reason to use brew.

[personjerry]

I think that's a false dichotomy. I think there are plenty of "normal" Apple consumers who may not be an HN-level hacker but would still be considered "developers".

[apocolyps6]

What is a "HN-level hacker"? I write code for a living and I read news on this website. Do I count?

I'm an apple "consumer" because I don't want to think about any hardware gotchas when I'm trying to do my job. That's the same thing I want out of my package manager, sensible defaults I don't have to think about so I can do real work instead.

[LiberatedLlama]

Homebrew has clear value even if you aren't a developer. It's the best way to install a whole lot of software, not just dev tools.

[nvr219]

I'm not a developer and I have plenty of reasons to use homebrew.

[fishywang]

I already stopped using Mac, but for people still using Mac: you really should give nixpkgs a try.

[milch]

+1. I’ve been using it for a while, and it fixes my problems with homebrew - mostly that homebrew breaks features every couple of weeks in small point releases, which you get automatically upgraded to

[NegativeLatency]

Auto upgrade sucks but it is possible to turn it off

[fishywang]

But then what? You still have to deal with the mess when you do manual upgrades.

[theshrike79]

Nix seems to be the Crossfit of the computing world.

How do you know someone uses Nix? They'll tell you :D

[jacobsenscott]

How does it "command you how to use your computer?" A brew formula is a simple ruby script that lists the packages dependencies, and calls "make; make install". Typically it allows you to set any autoconfig vars and remembers them for next time. This is literally just a thin layer of abstraction over grabbing the tarball and installing the software yourself.

Also brew does not stop you from installing a piece of software literally any other way you prefer if for some reason you don't like what the brew formula is doing, including just creating your own tap.

[sneak]

I find Nix to work better on macOS than Homebrew, and it doesn't embed spyware in the package manager like Homebrew does.

[bzb6]

Ah, this reminds me of how shitty the maintainers were to me when I said I was using hackintosh (for an issue that had nothing to do with it).

[Hackbraten]

Apologies about that. I’m sure none of us wants to be shitty to anyone. It’s never ok when we are.

[busterarm]

You left out the entire generation of developers who are totally disconnected from how systems work and think that "it runs on my machine" should be good enough.

Brew has lowered the bar enough that lots of folks simply don't have a clue how to deploy anything and worse, don't have a clue how to troubleshoot when something goes wrong in production.

Obviously it's a double-edged sword. It's good to not waste time configuring your workstation, but ultimately I'd argue in brew's case too good to be true.

[jacobsenscott]

This makes no sense. First, nobody deploys anything to macos in production. Second, dragging an icon the applications folder (pre-brew method) does not "connect you to how the system works".

[panopticon]

I don't understand this critique. Is this a complaint about package managers in general, or is `brew install git` lowering the bar from `apt install git`?

[busterarm]

It's about a trend of developers who don't know how to interact with their system beyond `brew X Y` and the disconnect between the software on their Mac and the software on a production system.

There's a huge disconnect between A & B so much so that it's created an entire role for people like me that otherwise shouldn't exist.

I've been in the industry long enough to see a decline in ability for lots of developers beyond kicking deployment over the wall for someone else to figure out (not that this didn't exist before).

Notice how many companies have dedicated DevOps roles in their ranks whereas everyone and their mother who is a practitioner has been saying since the very beginning that that's now how it should be.

[mercer]

Your complaints seem to boil down to "get off my lawn" and it's rather tedious. what do you get out of it other than a feeling of superiority?

[busterarm]

It's not at all. It's a reaction to the learned helplessness from colleagues I've had to work with. It's exhausting to be relied upon for everything, especially when the compensation isn't matched appropriately (although most management I've encountered have appropriately engineers who do disproportionate heavy lifting). Our industry needs to do better.

[panopticon]

I don't buy the premise that package managers are the reason why companies need DevOps.

Software deployment has gotten complicated for a variety of reasons (containerization, micro-services, continuous integration, cargo-culting FAANG practices, etc). When I first started my career, I FTP'd my code changes into the single production server that ran both Apache and MySQL. Homebrew is not the reason I don't do that anymore.

[busterarm]

That's not really the argument that I'm making.

I am a deployment engineer.

Deployment is actually really easy.

I'd argue that it's not far off from FTPing your code changes over in terms of difficulty.

No, my argument is that more engineers today do not know how computers work. I'd even argue that many engineers would find FTPing over code changes to be too difficult (or they'd screw it up). My argument is that homebrew makes some amount of contribution (not 100% the reason for) engineers remaining ignorant about computers.

[bluefirebrand]

> Notice how many companies have dedicated DevOps roles in their ranks whereas everyone and their mother who is a practitioner has been saying since the very beginning that that's now how it should be.

I dunno who says that but they're dead wrong. I'm working as a dev somewhere with a dedicated DevOps finally after years of being dev + ops (+dba +sysadmim +qa) and I can't tell you how much of a relief it is to have other people shoulder that stuff so I don't have to think about it.

I understand your point that devs who have a higher level understanding of systems and deploy pipelines and such are probably able to write good systems themselves, but when it comes to the humans doing the work? I absolutely love having it separated.

[busterarm]

It feels nice but organizations with cross-functional teams are outmaneuvering yours and probably by at least 3x.

I'd rather work harder at a business that succeeds and has equity that's worth a damn.

[TameAntelope]

Well, to be clear, developers who say "it runs on my machine" aren't a "new generation of developers" so much as "bad software developers".

There's no world where that excuse is okay. It's also not all that related to Homebrew, though...

[upbeat_general]

Not everyone wants to troubleshoot things in production. In fact I’d argue most people dont want to do that.

I’d certainly prefer to stay away from that type of hassle when I’m just trying to install a random package.

[busterarm]

Nobody's saying you should want to.

This is a conversation about ability level.

[kspacewalk2]

"Someone else would have filled the void if homebrew hadn’t shown up, and it would hopefully have been better."

MacPorts and fink existed before homebrew took over, and they weren't better. That's why homebrew took over.

[quesera]

But Homebrew wasn't (and isn't) better than MacPorts, either.

They both work well (we can and do quibble about the internal mechanics of each), and appeal to different groups of people.

My theory is that Homebrew was announced at exactly the right time in the MacOS adoption curve. A huge number of new users arrived with no existing knowledge of MacPorts or Fink. Most of them didn't know they needed a package manager at first, but when the momentum picked up, Homebrew was the new option with a better web page, a more collaborative working model, and hosted at GitHub (also ascendant).

I'd also argue that similar factors were involved in Linux's popularity over BSD in the 1990s.

Timing, environment, adequacy, and luck. All are required. Superiority is not.

[selfsimilar]

About 11 years ago I moved over to then OS X and Homebrew was very new compared to MacPorts at the time. I started with the more established MacPorts, but quickly became frustrated with how many broken and outdated packages were hosted on MacPorts. So I moved over to Homebrew and haven't looked back.

This is not to say that Homebrew is perfect; there's lots of big and little things I'd change. But I'd argue that at least at the inflection point of its introduction, Homebrew definitely solved a problem I was having with its competition. Timing helped for sure, but in my experience it won on technical merits.

[kstrauser]

I'm in that same boat. Homebrew irks some people, but for me it's always just worked to the point that I just don't have to think about it, ever. That's what I really want from a package manager: to be able to forget that it's there and start taking it for granted.

[volta83]

I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked.

Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.

[thaeli]

This, so much this. I tried to use MacPorts. It was pulling teeth every time. Brew was a It Just Works breath of fresh air.

I agree that it's a very opinionated tool, and note that those opinions fit in well with the Mac ecosystem. They aren't as good a fit for Linux or Windows.

[novok]

I think often 'it just works' and 'opinionated' goes hand in hand. Without choosing what to say no to, you create infinite workload with finite amounts of people and thus something breaks, somewhere.

[jacurtis]

Yep, I have to agree. I started using a mac about 11-12 years ago. Homebrew was new. At the time MacPorts was the "defacto" package manager and Homebrew was the "new kid on the block" or "experimental" one.

I started with Macports and it never did what I wanted it to. Packages were broken and it required me to do a lot of stuff that I didn't understand. A friend told me that he had recently done all the same installs on Homebrew and it was easy. So I gave Homebrew a try and the exact same packages installed easily and quickly. Homebrew has only gotten easier to use since then.

Maybe I am just not doing anything complicated enough with Homebrew to run into the issues other people have had, but my experience with Homebrew has been a breeze. I really don't have any complaints. I'd maybe prefer if packages were Python instead of Ruby, but at the end of the day that really doesn't matter.

[tclancy]

Same. I wrestled with it and Fink for a while. Maybe things have gotten a lot better elsewhere and I have Stockholm Syndrome, but so far so good.

[jasonwatkinspdx]

I used MacPorts before Homebrew was a thing, and had plenty of experience with bsd ports going back to the late 90s.

Homebrew was just straight up better, no doubt about it. It wasn't "noobs," "good timing," or "tricky marketing." They were just better, even if still not what these posters desire.

[brmgb]

> They were just better

No offense but we are talking about a "package manager" which:

- complained when you installed things in /use/local (where they belong) not managed by itself;

- had a flag to install packages somewhere else which broken half of the packages because they were so poorly written and no one was checking;

- messed with the permission of the file system for no good reason wahtsoever;

- would fail to properly update its own package list if you waited too long because the way they used git was broken beyond belief.

As I never had any of these issues with MacPorts, I might suggest you have a very low ceiling for what you call better. It pains me so much that you have to use Homebrew if you want to have recent packages.

[quesera]

You're imputing far more judgementalness than I intended.

As for better vs worse, let's just say that opinions vary.

[tristor]

> But Homebrew wasn't (and isn't) better than MacPorts, either.

Hard disagree. Maybe that situation has improved for MacPorts, but when I made a decision to move from a Thinkpad running FreeBSD to a MBP for work, I gravitated immediately towards MacPorts and found it to be horrendously broken and significantly less friendly than using Ports on FreeBSD. I was expecting a similar UX, and found something that had the trappings of Ports with none of the underlying maintenance that makes it actually work.

Then someone recommended Homebrew. I tried it, and it worked perfectly the first time. I actually kept both on my system for awhile and tried to make MacPorts work, but eventually over the years I gave up on that and I've been a Homebrew user now for more than 5 years. Homebrew is strictly better in the most important factor: It actually works.

[cmehdy]

For some users I would argue brew was indeed better - I can't judge for the technical level, but definitely so for the UX and troubleshooting.

I might have liked MacPorts with my current experience, but when I first needed to install CLIs and tools I did not have extensive knowledge of shells and paths and such, and MacPorts felt significantly less "integrated" especially when something would fail (as opposed to brew occasionally just asking if you want to overwrite symlinks essentially).

I'll never know if MacPorts was better once you're past the initial hurdles since I'm so used to brew these days, and I believe that sort of experience is probably not isolated. Given the propensity for Mac users to want something that just kinda works and gets details out of the way, I can see why brew succeeded.

[quesera]

You're probably right about Homebrew feeling more comfortable for new users.

Opinions on Homebrew may diverge with the answers to "How would you prefer to install? a) curl pipe to shell, or b) Download a DMG, double-click to install, and update your PATH." :)

[Macha]

a) curl pipe to shell

b) Download a DMG, double-click to install

These are not morally that different, the DMG installation can also do pretty much whatever, and I doubt people are picking apart the DMG to find the install script to verify that either.

[quesera]

I'm definitely not resuscitating that old argument here.

Just noting that people have strong opinions about the preferability of either approach.

[the_other]

I tried MacPorts. Then I tried brew and stopped using MacPorts. Maybe I just don't use my computer the way you do?

[saurik]

Homebrew "took over" because of a combination of web 2.0 marketing that prematurely shat on its competitors while claiming it was the "modern and beautiful approach" while ignoring hard-learned lessons about the extents to which Apple doesn't care about breaking things and removing programs or libraries from their base system--the Homebrew people were really pissy about "MacPorts insists on installing its own version of X... I already have X!" and would claim "Apple used to chance stuff back six years ago, but they surely stopped by now" and then slowly had to relearn this lesson over time--or supporting binary packages (which both fink and MacPorts had great support for, but the Homebrew people insisted on ignoring that as part of the "I shouldn't have to recompile the world to install software", which was nonsensical) or even basic security mandates (some of which they still haven't fixed, such as the insecure way they handle /usr/local). It was honestly ridiculous, and they only really got to a place of being "better" only by eventually becoming more like the things they insisted were dumb and by capturing all of the new blood contributors mostly due to messaging/marketing (and so eventually ending up in a state where new software now ends up being brought to brew by default). If anything, the only thing I can think of where Homebrew even slightly offered an "advantage" worthy of arguing "this is why they won" is by choosing to dump their stuff in /usr/local instead of making a new root (such as Fink's /sw or Nix's /nix) or carefully next organizing it under /opt (such as was done by MacPorts), which did in fact mean that more software tended to just detect automatically stuff (as some things do their own searches instead of using configured environment variable search paths).

[kergonath]

Thanks. It’s nice to see I’m not the only one remembering their arrogant attitude and approach to development, or with these concerns about technical details. It’s unfortunate that Macports became the boring one compared to Homebrew’s new hotness, because Macports is the better design, TCL port files notwithstanding.

[Gelob]

+1. i like it but yes if i dont use it everyday and 2 weeks later go to brew install something, omg it has some gigantic update to do before i can brew install anything.

[pwinnski]

That is frustrating, but fortunately `HOMEBREW_NO_AUTO_UPDATE=1` will take care of it. Then you have to remember to update every now and then yourself, though.

[m000]

Would you happen to know how to disable upgrading unrelated packages?

I often do `brew upgrade X`. Brew indeed does what is necessary to upgrade package X + deps. But then goes on and starts upgrading unrelated packages.

[jacobsenscott]

Brew does not start randomly upgrading unrelated packages.

Packages have dependencies, and those dependencies have dependencies. Try `brew deps ---tree x` to see all the dependencies for you package.

Look at `brew pin` to pin packages you don't want brew to upgrade.

Many formula are versioned. For example if you install `postgresql` it will do major upgrades of postgres as they become available, but if you install `postgres@9.6` it will only install updates to 9.6.

[dylan604]

so, you don't do a 'yum update' before installing software on your system (or 'apt-get update' or whatever)? Are you also the type of person that refuses to update system software because "it takes too long, and I'm too busy"?

[wpm]

No, I don’t like forced 5 minute stops to my work.

Yes, I’m the type of person who only updates on my schedule when notified, or when I need something.

These little tools installed by home brew aren’t just little tools, they’re dependencies for whatever else they’re used in. The fact that I need package “X” doesn’t mean I want package Y, something entirely unrelated, updated without my consent.

It’s MY fucking computer. Let ME decide what software gets installed on it and when.

[ratww]

Not GP, but I do it quite often, but not every single time. Also yum/apt/etc updates are way faster and much more responsive than brew.

[eknkc]

I generally don't do an apt update before installing a package that I needed at that moment.

However I do full update / upgrades when it is convenient for me.

That's the point.

[Schalter]

I have the same issue and for me there is a simple difference:

I probably use homebrew for a handfull of tools, in debian etc. my packagetmanager manages everything.

Its not a huge issue but the thought of 'ah shit i need to run update' comes with 'that will be slow'

[loriverkutya]

When I get angry about brew sucks I always remind myself there is npm.

[cmehdy]

When I get angry about npm, I remind myself there is gradle.

[Gaelan]

When I get angry about gradle, I remind myself there is autotools.

[martpie]

The usual non-productive rant.

What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project?

"It sucks" doesn't help anyone understand your frustrations and does not serve the message you're trying to share (let this one be valid or not).

Also, as everything that is open-source/free: if you hate it, don't use it, that's it. And let the people who appreciate it be productive and build awesome tools with it.

[biktor_gj]

Not parent, and I'm not going to say it sucks, the project takes a lot of work from a lot of people and I ain't the one pissing on other people's work, it definitely could use some improvements syntax wise though, What was it, brew install? Brew cask? Oh , now is brew cask install... or was it brew install --cask?

I get the analogy, but being a package manager, but was it really that bad to use 'brew install', 'brew update', and 'brew upgrade' for everything?

And it's true that it is a little frustrating at times when you don't use it for a while, you 'brew install xx' and wait 4 minutes until "Updating homebrew" finished with its dozens loops between shells, ruby etc doing its stuff (which I assume is refetching repos, but couldn't know it from the output)

I use it because it's the most common thing for mac, but I miss APT and DNF everytime I use it, not going to lie

[latexr]

> I get the analogy, but being a package manager, but was it really that bad to use 'brew install', 'brew update', and 'brew upgrade' for everything?

That’s how it works now. You only need `--cask` for (rare) disambiguations.

Homebrew Cask started as a different project (casks and formulae are still inherently different), so not having `brew cask` only became viable after the two projects merged.

> it is a little frustrating at times when you don't use it for a while, you 'brew install xx' and wait 4 minutes until "Updating homebrew" finished

Use `HOMEBREW_NO_AUTO_UPDATE=1`. Just don’t open an issue if something breaks and you didn’t update beforehand.

> which I assume is refetching repos, but couldn't know it from the output

`--verbose`.

[MarkyC4]

Homebrew (and CocoaPods, perhaps famously) uses github as a CDN for their package listings, syncing the git repos likely takes the most time here

[senjin]

Do you mean apt or apt-get or apt-get install or was it apt-install --get?

[Schalter]

even on old infrastructure its already apt and nothing else anymore. So they advanced.

[FireBeyond]

No, it's really not. apt-get works just fine on my current Ubuntu instances.

[w0m]

> What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project?

I think ~everything he stated is generally assumed true. I use Brew installed software every single day, and appreciate it. That doesn't put it above criticism though.

[bakedbeanz]

"brew fucking sucks" is just whining, not reasonable criticism IMHO

[bastardoperator]

There is no criticism in their statement though, just a generalized opinion/rant that doesn't point out single issue and is factually inaccurate.

[zimpenfish]

> doesn't point out single issue > is factually inaccurate.

I think these two might be somewhat contradictory.

[bastardoperator]

I don't, he said someone else would have filled the void, there was no void considering this project came after macports and fink

[curun1r]

> What prevents you to do it better then?

The mindshare of nearly the entire community that develops software for the Mac. Homebrew, the tool, is inferior to several other options, but developers of software treat it as the one true package manager on Mac. It's so frustrating to see projects offer it as the only supported way to install their software on Mac apart from building it from source.

Your question reads like "What prevents you from building a better social network than Facebook?" response to criticisms of that platform. And the answer is that in a tool like Facebook or Homebrew, all the value is in the ecosystem. Building a better tool is useless until everyone is using it. And no one will use it until everyone else is using it. It's a classic network effect, and it inhibits viable competition.

[Zarel]

I think the big difference is that Homebrew, unlike Facebook, is open-source (and doesn't have a huge trove of data to protect, leading them to go after third-party clients).

It's plausible that you could just write a front-end that keeps using the same remote package repository, that fixes everything you complain about.

I suppose it depends on what exactly your complaints are, but most of the complaints here (CLI, auto-update, etc) seem like they could be addressed with just a client fork.

[overgard]

> What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project?

Time?

> Also, as everything that is open-source/free: if you hate it, don't use it, that's it. And let the people who appreciate it be productive and build awesome tools with it.

This is such an unhealthy attitude. Just because something is free doesn't make it above criticism. Also doesn't mean that the maintainers don't benefit from their projects even if there isn't direct compensation (more career opportunities, visibility, etc.) This idea that we need to walk on eggshells around anyone that does any volunteer work is kinda absurd.

[FemmeAndroid]

> Just because something is free doesn’t make it above criticism.

What was being responded to wasn’t criticism. It was whining without any substance.

[one-punch]

> I hate that brew is good enough that it’s got some kind of local maximum such that there’s no replacement forthcoming.

You may be interested in trying out nix for package management [1], or even for configurations and providing development environments (see my other comment [2]).

[1]: https://builtwithnix.org/

[2]: https://news.ycombinator.com/item?id=26038614

[novok]

When I tried nix on my mac a while back, it took forever to install basic things, had very verbose logs, was far more complicated and was missing packages. Is it still like that?

[ris]

Nix on macos only got a pre-built binary cache a couple of years ago - before that, yes, almost everything had to be built from the ground up.

[soraminazuki]

Not my experience at all.

[my123]

MacPorts meanwhile existed years before Homebrew, and is alive and well.

[eyjafjallajokul]

Mate, can you tone it down a little? Your opinion is fine but it’s unnecessarily inflammatory towards basically volunteer work.

[throw0101a]

Besides the already-mentioned MacPorts, NetBSD's pkgsrc is multi-platform, including macOS (AFAICT):

* https://www.pkgsrc.org/

[jperkin]

macOS users may want to use my binary package repository, updated every few days from pkgsrc trunk:

https://pkgsrc.joyent.com/install-on-osx/

[smazga]

Yeah, it works on macOS and is actually very nice, but its package catalog is not quite as comprehensive and OS upgrades are a huge headache. In other words, a solid alternative with a different set of issues.

[upbeat_general]

It’s hard to disprove this but IMO brew is the best package manager I’ve used (at least out of any of the widely used ones). I’m sure there is a better way to do things but given other common package managers that I find to be much worse, I’d argue it’s equally (if not more) likely that the alternative to homebrew would be worse.

[onedognight]

    export HOMEBREW_NO_AUTO_UPDATE=1

[filleduchaos]

That doesn't solve the evergreen packages problem, and I'm tired of people trotting out this flag when people (rightfully in my opinion) complain about brew upgrading literally everything it can get its hands on.

[qntty]

What do you mean by random unwanted updates? As far as I know, the only way to update is by running brew upgrade.

[stonesweep]

To codify both replies to yours as an outsider who watches macOS coworkers struggle: brew is akin to running Arch, where the concept is latest-tagged-release of any given software.

The newest version of X introduces a feature which has a need of Y library (dependency) >= n+1, where n is your already installed version. It just so happens that Y is shared between 3 applications; so if you upgrade Y to satisfy X, you now have to recompile/upgrade (depending on details) A, B and C as well to use the newly updated version of Y.

Arch (and other rolling releases) do/does this every day, it's just that the work is offloaded to upstream packagers. Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.

[Hackbraten]

> Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.

I don’t see how Homebrew would be similar to AUR.

Unlike AUR contributors, Homebrew maintainers curate the packages, test them, monitor upstream projects for updates, build and upload binary packages and do their best to support users when anything breaks.

Anytime a Homebrew user installs a formula from homebrew-core and the system starts to (re-)compile, almost certainly something is wrong.

[stonesweep]

It depends on the formula, designs and maintainers of them - we run an internal tap and some items are casks, some are bottles and some are compile as you go. It just depends on what that widget is and does, and in some cases there are tools which are broken on latest-tagged releases and people have to pin older versions or using git HEAD for (some period of time) until the tagged released is fixed upstream. (we're looking at you, sshuttle-who-deprecated-remote-python2-in-v1.0-thru-1.0.4-and-broke-lots-of-workflows-with-jumphosts)

[ilikepi]

For some time now, in the default configuration, `brew upgrade` is run automatically any time you run `brew install`. You have to set HOMEBREW_NO_AUTO_UPDATE to disable this behavior.

EDIT: whoops, that was incorrect. It's actually `brew update` that is run automatically, which updates Homebrew itself plus all of its formulae. However, I think often the effect can't be similar. If formulae are updated, and the new package you're trying to install shares a dependency with other packages, the dependency will be automatically updated as part of the install process. I'm not sure if this can also trigger an update of an existing leaf package though.

[bargsteen]

Yes, figuring this out I created an alias a few months ago. #LifeImproved :D

Add this to your .zshrc or equivalent (f for fast):

alias brewf="HOMEBREW_NO_AUTO_UPDATE=1 brew"

[w0m]

Personally; only issue i tend to have is that when I install X, it breaks Y forcing reinstallation of ~everything. What should be a small install ends up taking 30m of cleanup.

Entirely likely it's user error on my part; but also problem I haven't really had with other 'nix package managers.

[Doctor_Fegg]

Which isn't funny when Y is Postgres and your database is no longer readable post-upgrade. Happened to me.

[regulation_d]

one time i ran “brew upgrade ffmpeg” which somehow forced a major version bump of postgres.

[juandazapata]

I installed awscli and somehow emacs ended up installed in my system.

[peteretep]

I ran `brew install graphviz` today and caught it running an upgrade of zeromq

[jeremycw]

I ran `brew install graphiz` a week ago and got a new major postgres version.

[yardie]

Macports? They’ve been around even longer than brew. But they were always a bit too Linuxy for most Mac users.

[flemhans]

I always thought that brew was the "Linuxy" one and Macports was FreeBSD Ports for the Mac.

[sirn]

Jordan Hubbard was involved in the creation of both FreeBSD Ports and MacPorts (DarwinPort), so it makes sense that it shares the BSD ways of doing things. His decision to use Tcl for MacPorts also came from his experience dealing with Makefiles[1]

[1]: https://netbsd.org/gallery/10years.html#hubbard

[yardie]

Well I don't mean Linuxy in the architecture sense but Linuxy in the preparation and final stage installation sense. Like Homebrew does not need elevated privileges to work and actively discourages it. MacPorts, when something breaks, is a rabbit hole of elevated commands to bring it back to functional.

Of course this is my opinion as I had Macports and Homebrew installed on my MBP 2012. I've swapped to a newer MBP and I only have HB installed. Since most packages are on HB I no longer need to have both installed.

[sirn]

> Like Homebrew does not need elevated privileges to work and actively discourages it

It does this by chowning /usr/local to a local user, which is worse for security than running sudo because now any malicious process can overwrite /usr/local/bin/bash without asking for privileges. macOS having /usr/local/bin in its $PATH by default also doesn't help. Homebrew made this security vs usability tradeoff because most Mac users are a single user, which makes sense in its context.

The recent change of moving Homebrew to /opt/homebrew (at least for M1 Mac) is a better solution for this as it is no longer in the default $PATH. On the other hand, MacPorts approach of requiring sudo allows it to drop privileges to other unprivileged non-admin user (macports) during build in addition to building everything via sandbox-exec.

[LiberatedLlama]

Running untrusted software on these sort of systems is fundamentally broken, no matter what the package manager chooses chown or not chown. A malicious program could edit ~/.bashrc to modify the user's PATH, or wrap sudo with a keylogger then use that password to chown anything it likes. That's not even a theoretical but unlikely sort of attack; it's quite trivial.

    > alias sudo='echo not what I expected'
    > sudo foo
    not what I expected

[sirn]

That's fair, but it's only affecting single user, while writable /usr/local affects all users. However most Mac users are single user, so the tradeoff makes sense in this context.

[eecc]

Linux? Macports take direct inspiration from FreeBSD ports

[brailsafe]

This seems like a rather exceptional, unsubstantiated, and mean spirited take. I've run into some strange issues with brew over the years, but compared to npm and apt it's been far less prone to causing me headaches.

[gagarine]

I rage quit Homebrew to MacPorts. No complain after 2 years. Not a single bug. Installation are much faster than 10 years ago too (macports use pre-compiled binaries now). Give it a try if you have some time to lose.

[smoldesu]

I agree with you wholeheartedly. Homebrew was my least favorite part of the MacOS experience, which is a shame since it was basically the most important piece of software I had installed on that thing.

[prpl]

It might not cover everything, but it also has a superset of other things more - conda + conda-forge (with mamba too for better performance)

The had also apple silicon support for many things more than a month ago.

[jacobsenscott]

brew is an amazing achievement. It doesn't do random unwanted updates at odd times. It doesn't do anything at all unless you run run it. And it tells you want it will do beforehand. Nobody would have "filled the void" - building software isn't a zero sum game. If someone had something better they would have continued to work on it and it would have "taken over". There, I said it.

[NicolaiS]

That is incorrect. Brew will do random upgrades when running `brew install` unless you set the non-default `HOMEBREW_NO_AUTO_UPDATE=1` [1] so every now and then when you brew install something it will e.g. upgrade the python binary from 3.x => 3.(x+1) and break all virtualenvs using symlinks. Python is just one example, I've spend countless time fixing random broken packages due to the unpredictability of `brew install`.

[1] https://github.com/Homebrew/brew/issues/1670

[jacobsenscott]

This is just a misunderstanding of how brew works. Brew is doing what it is designed to do. Your assumptions are that brew should be able to "pin" a package to an exact version, or that it is selecting packages at random to upgrade, but those assumptions are wrong.

https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-also-...

However brew does support your use case, but it take some extra effort. If you want to use brew to install an exact version of python you need to create a tap: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap

Also, you aren't forced to use brew to install that version of python. You can do so yourself using the standard make; make install. It would be best to install it under /opt. Or use any other available method of installing software on your mac.

[tomlin]

If you've used Valet, you know truly that Brew is the worst.

[game_the0ry]

I am cool with constructive criticism, but you do realize brew is free, right?

If you are not happy with open source, you have a couple of options:

- build your own brew

- brew is open source, so you can make contributions to improve

- pay for something like brew (though probably not an option for brew)

Have you done any of the above before complaining? I am guessing - no. Otherwise, say "thank you" and move on, my friend.

[Enginerrrd]

I get where you're coming from, but I think the open source community benefits from being, well, open. Walling yourself off from user frustrations and criticism with the attitude that they are ungrateful is not how projects evolve to better meet user needs.

[dmitriid]

Being free doesn't absolve it of criticism.

[oreille]

You sure sound absolutely cool with criticism.

[volta83]

> There, I said it.

What a waste of bytes and bandwidth. "[homebrew] It’s the worst package manager I’ve used" is true for all users that have only used one package manager. The opposite claim ("it's the best I've used") would simultaneously be true.

You could at least have mentioned _why_ and that could have kickstarted a meaningful discussion, but instead your comment is the equivalent on a thumbs down in a youtube video.

[anaerobicover]

Pot, meet kettle:

https://news.ycombinator.com/item?id=26037357

> volta83 1 hour ago | parent [–] | on: Homebrew 3.0

> I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked.

> Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.

> reply