Hacker News Reader

Comment by civilized | Hacker News Reader

A lot of the usual "it's bad" "it's not bad for me" discourse in these threads. Could people raise the bar a bit and talk about specific problems they have had with homebrew - other than the auto-update, which we've already noted can be changed by setting HOMEBREW_NO_AUTO_UPDATE=1? Thanks.

View on HN

Certainly. For me it started when they removed the entire scientific stack, which broke my install scripts / brewfile. Then, they removed the ability to customize builds, which broke my emacs build. Also hit the OP issues.

In every case they were removing features that were working just fine, and in the process creating work for me. Got fed up, switched to macports (after checking out nix), and so far things are back to the way I like it.

It's hard to pinpoint what the problem really is, but me and a few colleagues had corrupted brew installations lately, where various things would just randomly stop working after updating a single package.

The trick of disabling auto updates doesn't really work when you do want things to be updated. Sometimes there are conflicts and the usual path was to upgrade everything.

Not that it matters: it seems that the usual "upgrade everything" from 2 years ago has changed into "delete every folder and reinstall everything from scratch".

Also, a few years ago, updating everything or reinstalling lots of things from scratch was fast. Now, it requires much more time due to the massive number of dependencies every single package has.

Also, the maintainers have a super weird aversion to everything that is "too simple". I've seen packages rejected because "the build process was too simple and there are no dependencies". The excuse was that "users can build it themselves". This is not for silly stuff random people wrote on weekend, this is for 20 year old tools used in production written in C.

I can't say for certain why or how it got worse for other people, but for me it started when they doubled down on dynamic linking. That's why installing takes 5x the time it used to, takes more disk space, breaks all the time and makes organising your tools a fucking mess.

As for me: I've replaced most of my Brew usage with Docker (for most development tools) or with static binaries compiled weekly using Github Actions (for cli tools like youtube-dl, etc). I'm also using download links straight from language websites (Rust, Ruby, Python, DotNet, Haskell).

> Also, the maintainers have a super weird aversion to everything that is "too simple". I've seen packages rejected because "the build process was too simple and there are no dependencies". The excuse was that "users can build it themselves". This is not for silly stuff random people wrote on weekend, this is for 20 year old tools used in production written in C.

wtf? What could be the possible motivation for this? Is their build farm really straining or something?

Can you point me to this example?

> I'm also using download links straight from language websites (Rust, Ruby, Python, DotNet, Haskell).

this sounds downright medieval to me, like why even use macOS for development if the software management tools are so bad that that's what you're doing

> this sounds downright medieval to me, like why even use macOS for development if the software management tools are so bad that that's what you're doing

Because it's only one tool that really sucks: Brew. For the languages I specified, it works quite well. Even using C++ with vendored dependencies works better than average in macOS for me.

For most of those languages I mentioned, Brew already offloads the real installation and updating of the language itself to a language manager (via rvm/rbenv, nvm, pyenv, rustup, whatever), so it doesn't make a difference, except without Brew I get a more stable, officially supported, environment.

Also, DotNet was a Cask until a few months ago, so they effectively were just downloading something from the official website just like me.

Could you give (or point to) a description how compiling binaries using GitHub Actions can be done? Sounds really nice. :)

Sure!

     - Use the workflow_dispatch type so it can be manually triggered. Or schedule if you want it to run periodically.
     - Install dependencies like automake/cmake and libraries using brew (I cheat here a bit)
     - Clone the repository
     - Perform the steps for building a static build
     - Use actions/upload-artifact@v2 to upload the executable.

It's simple, although to get it right with some programs. The advantage is that with one click you can download it, put in your path, and it won't need special paths.

Here's an example with jq: https://pastebin.com/gHu8dTgQ

Honestly the best option is asking maintainers of each program to add a static build to their projects in order to make their projects able to run without installing dependencies. Problem is, some maintainers are very anti-static-compiling.

They deprecated the "brew cask install" then completely removed it only ~20 days later (in late December!), breaking many other projects in the process.

I'm a bit wary on relying on it now. It's a shame, because it's a really useful tool (and I actually like the auto-update).

My preference for MacPorts starts from the fact MacPorts keeps their files separate from the system files. To uninstall, just delete the folders.

I’ve seen homebrew overwriting system files and thoroughly breaking machines (that’s no longer that easy, but more thanks to Apple).

Haven’t tried many other package managers (Fink, when G3 was bleeding edge), but MacPorts has the feel of an exquisitely well engineered tool.

Homebrew staff have rejected the concept of automatic upgrades for security, stability, and semver: https://github.com/Homebrew/brew/issues/3428

One thing has ruined my week is running brew upgrade $package instead of brew update $package. One of those commands will update the package and the other with update everything you’ve ever installed with Homebrew.

Reply on news.ycombinator.com