Hacker News Reader

Comment by falcolas | Hacker News Reader

With all of the - I'd call them shenanigans, but I'm sure they're justifiable features [0] to someone - with homebrew, it may be time to take a closer look at macports as a replacement. Glad to see the project not only alive, but evolving with the community.

[0] Like automatically running `brew update` with every brew command run. I was literally wondering if my computer had frozen up again when I saw that it had done a full update (which involves not only patching the brew code, but updating its source repos) before installing a pre-compiled version of tmux.

View on HN

Wow, that's almost as bad as a few months ago when they enabled the analytics feature that sends data to Google Analytics for every brew install, list, search, error, etc[0]. Thanks for pointing this out, I've disabled the auto update (HOMEBREW_NO_AUTO_UPDATE=1). Web developers gone crazy with the package manager in your shell!

[0] https://github.com/Homebrew/brew/blob/master/share/doc/homeb...

> automatically running `brew update` with every brew command run

This is not accurate. We run a minimal version of `brew update` at most once per minute when you run `brew install` or `brew upgrade`: https://github.com/Homebrew/brew/blob/5504e2c1320d52f8a92a33...

You can set this interval with `HOMEBREW_AUTO_UPDATE_SECS` and disable this functionality with `HOMEBREW_NO_AUTO_UPDATE`.

> at most once per minute

Well, that's a relief. I run an average of 4-5 brew commands every minute, so at least there's that. /s

> when you run `brew install` or `brew upgrade`

So, only the two most used `brew` commands (for me, at least) will trigger a series of git fetches and merges over the network and an in-place update of the code.

> You can [...] disable this functionality with `HOMEBREW_NO_AUTO_UPDATE`

Why was it enabled automatically in the first place? Why wasn't I notified when homebrew updated that this was the new default behavior. Why must I always dive into homebrew on github to identify (1) why it's not behaving the way I would expect a package manager to and (2) how to get back sane package manager behavior?

> will trigger a series of git fetches

If there's been no updates there will be no `git fetch` run. We use a newish GitHub API to check for updates as its quicker.

> Why was it enabled automatically in the first place?

A significant numbers of our created issues are due to people having failures when they don't run `brew update`. This solves that.

> Why must I always dive into homebrew on github to identify (1) why it's not behaving the way I would expect a package manager to and (2) how to get back sane package manager behavior?

We're an open-source project run by volunteers for free in our spare time. We're underfunded and understaffed so our communication is lacking. The best current place to find out about such things is to follow our issue tracker. We aim to improve this in future.

Yeah, that one surprised me too recently. But most of the junk can be disabled. My current settings:

  $ env | grep HOMEBREW
  HOMEBREW_BUILD_FROM_SOURCE=1
  HOMEBREW_NO_AUTO_UPDATE=1
  HOMEBREW_NO_EMOJI=1

Can you disable all of its cutesy names? Bottles for binaries, cellar for package path, taps for 3rd party repos, recipe (or formula? I forget) for build scripts, cask for a REPL... I honestly got a bit confused at first by what all of these things meant.

This habbit of programmers to name things with puns instead of descriptively drives me batty. WiX is bad, but Homebrew is on a whole new level.

Each time I use a mac I have to relearn what a tap represents vs cask vs brew vs celler etc. But hey, aren't they clever with words!

I don't get it either.

Chef does the same; it has chef, knife, kitchen, berks, recipes and more. Getting started with it is a freaking nightmare.

Everything has cute logos and names and good looking README.md files to lure you into using it then you're trapped into hell.

Try Googling for Chef Knife when you're lot logged in as well and it's a total nightmare.

It's hipster programming kitsch. It's unnecessary and indicative of the culture of its developers and early adopters.

There wasn't a problem with MacPorts / Fink, they are built on top of proven mature tech (FreeBSD ports and Debian's apt), but why not reinvent the wheel? All the cool node kids are doing it.

I switched because I had to nuke my entire Macports packages directory and start from scratch to fix one error or another several times a year. Got fed up with it and tried Homebrew ~3 years ago. Haven't had to do anything like that even once, so I've stuck with it.

Homebrew has all the markers of a project I should hate, but it's so rarely inconvenienced me in practice that I can't help but like it.

> I had to nuke my entire Macports packages directory

I'm not sure what you were doing, but this is scary. I've been using it since 2012 or so and never had as much as a hickup.

Perform an update or install a package, things break. Usually Macports itself would partially or entirely stop working. Not the same way every time. After the first couple times I learned that attempts to fix it usually didn't entirely solve the problem and/or took too long, so I just started deleting the whole thing and starting over when things went wrong. At least re-installing packages doesn't require my full attention.

2012 may have been around when I stopped using it, can't recall for sure. Maybe it improved after I dropped it.

Those clever words immediately made sense to me for their inherent meanings the first time I saw them. So they are actually quite useful in their pairings.

I love puns just like everyone else, but when you have a word that precisely describes the thing you have, why not use it instead of using a clever metaphor?

Like programs for Pages, Numbers, Keynote, Photos, Notes...?

Word! The picture you paint, drives a powerful point.

Well isn't that nice for the one person who intuits their meaning, for the rest of us we would like to not have to translate already designated words to new words for no other reason than to be playful.

Homebrew was the first package manager I ever used, and the cutesy names actually helped me understand what each part represented. I feel like I have a better understanding of package management thanks to the naming scheme.

This is why I use MacPorts.

That would be great. I don't find them intuitive at all.

You may also want to consider

    HOMEBREW_NO_ANALYTICS=1

to disable Google analytics being sent

There's actually an `analytics` command that saves you even having to manually do this. `brew analytics --help` shows the options.

Serious question: why would you want to do this?

Serious question: why would you want to send to Google details of the software you're installing on your computer?

It's not that they want to send it to Google, it's that they want to send it to homebrew, and google is an intermediary. Sending it to homebrew allows them to know what features are being used, so they know what features they could remove or improve.

If homebrew is transmitting the packages you install across the internet, through Google's servers, and through homebrew's system, it is very possible that information could be swept up in a dragnet or stored on a server that could later be subpoenaed or searched with a warrant.

The analytics issue aside, how can a package manager not transmit what packages you install across the internet? At some point it has to request the package(s) you're installing from somewhere on the internet.

Yeah, over TLS, and I generally presume that a simple request for a package won't be logged and recorded for posterity.

So don't use Google as an intermediary. Debian runs popcon, for example. They could run something similar.

It might amaze many of you to hear this but it's because I genuinely doubt Google will do anything nefarious with this data.

Because it's useful to homebrew. Analytics help software makers - that's why they exist.

[PS: that's not a serious question: it's completely facetious.]

Because it helps the ecosystem?

The main self-interested reason: we use analytics to judge what packages and options to remove. If no-one using analytics uses software: next time it requires non-trivial maintenance work it will likely be removed rather than fixed.

That's even worse - if I had a penny for every time a useful, but unpopular thing was shut down, I could fund my own startup!

And we could fund our open-source project to maintain these things. Sadly neither of us have these pennies ;)

you might also consider

    HOMEBREW_NO_ANALYTICS=1

I'd like to see pkgsrc take off as the big Homebrew alternative.

That, or nix. Unfortunately the state of Darwin/OS X on nix has declined over the last year or so.

How has it declined?

It seems less people are involved or interested in solving the Darwin related issues. I have more issues getting things built and installed on OS X compared to a year ago. This mainly because it seems people aren't really interested in maintaining the OS X part of nixpkgs and some simply lack the resources to do so.

In the end it seems that this will get better if it can attract enough OS X users so that patches start rolling in but right now it's just a few people fighting that battle.

I don't like the lack of software diversity, but I see running Linux based containers on OSX as a viable solution to not having Nix support. Run nix in a container, create shimlinks so that everything is "transparent"

Reply on news.ycombinator.com