Hacker News Reader

> Especially since homebrew force-updates itself and there's no way for users to avoid these changes.[1]

This is not true. `man brew` documents how to disable auto-updates.

> Why exactly is this kind of purist decision being imposed on users?

Because there's a lot of current debate about whether things being relicensed under the Commons Clause is "open source" or not and we'd rather lean on an established, well-documented authority on what that definition is. Additionally, part of our agreed membership of the Software Freedom Conservancy (who help us with a lot) involves ensuring our core formulae are open source software.

> So you're going to periodically make maintenance changes to my system without my permission. Goodie.

Again, `brew man` documents how to disable this.

---

The complaint behind the individual complaints is "why doesn't Homebrew work the way I want it to". That's a reasonable complaint and there may be better tools for you to use rather than Homebrew but we're going to continue to build Homebrew to work in a way that works best for the majority of our users and avoids our (entirely voluntary) maintainers having to deal with the same issues again and again.

Re auto-updating: thanks for that, which is something.

For those who haven't had a chance to dig through, prompted by this, I searched through the man page [1] on GitHub and apparently the environment variable to set is:

HOMEBREW_NO_AUTO_UPDATE

https://github.com/Homebrew/brew/blob/master/docs/Manpage.md

There's also `HOMEBREW_AUTO_UPDATE_SECS` (which I personally set) so you can still auto-update but do so a little bit less often.

As someone who uses homebrew religiously, but isn't familiar with the inner-workings, I'll second the sentiment that some whys on the changes would be much appreciated.

Otherwise it just looks like a bunch of scary behavior changes w/o a clear upside.

that's a really good suggestion. As someone that writes a lot of changelogs, they would really benefit from including _why_ and not just _what_.

I do think, however, that users greatly underestimate how much time it takes to write up a good changelog. Even one that is as simple as this.

Yeh, that's it in a nutshell, unfortunately. I wish I had more time to write great changelogs for Homebrew but I don't :(

I'd rather you write the code. Keep up the good work.

Hopefully these changes will allow you more time to focus on adding value to the vast majority of users. If a small subset of folks need the marginal functionality, it should be up to them to step up to the plate and make it happen.

Thanks for the kind words.

> Hopefully these changes will allow you more time to focus on adding value to the vast majority of users. If a small subset of folks need the marginal functionality, it should be up to them to step up to the plate and make it happen.

100% agree.

Not for me to tell you how to prioritize your time, of course, but I'll just say in my experience programmers tend to vastly over-index on the importance of stuff like crushing code and under-index on the importance of stuff like communicating w/ the community. Non-tech tasks are still hugely important.

Cheers, and thanks for your work on homebrew. It really is a great tool.

Thanks for the kind words.

For what it's worth, I really do value this stuff which is why we have release notes at all, a Discourse forum, etc. most of which I've setup and run :)

>So you're going to periodically make maintenance changes to my system without my permission. Goodie.

I suspect this is partly because the cache can consume a huge amount of disk space over time and many users might never run `brew cleanup` or doesn't even know about it. And then wonder where all their disk space has gone.

That would be a great reason to communicate with users in a prominent place in the docs. Sadly, the maintainers seem to always choose to force the user behavior that they see as desirable rather than communicate with users about it. For what is, at bottom, a developer tool this is madness.

Isn't it that what mac is all about ? "We know better, let us do the thinking for you" ?

Not sure if this is tongue-in-cheek or not but we do try to follow the/our perceived Apple approach of "sensible defaults which take the thinking out of using the tool". This means doing things automatically for users and letting them opt-out rather than requiring them to read all our documentation to know how to avoid e.g. a bloated cache directory.

I appreciate it. I can RTFM and figure out how to do a million ad-hoc maintenance chores for the thousand tools I use daily, but I'd rather not have to if those tools care more or less take care of themselves.

And let's be honest, most often Apple does know what's better for the average user.

Git also does internal housekeeping in the background when you pull. Actually most developer tools perform operations on their caches and other internal stores over time without asking or telling you about it, so this shouldn't really be a concern.

(a secret: we copied the time period that Git uses for its periodic housekeeping)

Yup, I just deleted 13GB of cache a few days ago.

> "brew update no longer migrates legacy keg symlinks, tap names, repository locations, cache locations or cache entries."

The biggest thing that has kept me on MacPorts and away from Homebrew is that I don't understand half of the terms that they use.

What is a keg? What is a tap? From the article you linked, what is a cask? What is the Caskroom? Elsewhere I've heard talk of "bottles" - what is a bottle, in this context? What are formulae?

When I started using Homebrew, I found those terms super intimidating and overly quirky but that went away quickly!

Keg: a dedicated subdirectory for each installed package.

Cellar: this is where the kegs are. Usually `/usr/local/Cellar`.

Formula: a file that tells Homebrew how to build and install a specific CLI package. (Similar to a portfile, I guess?)

Tap: repository of formulae, e. g. `homebrew-core` (the repository where Homebrew keeps all the core formulae)

Bottle: pre-built binary package. Homebrew usually builds and hosts them for you. At install time, Homebrew downloads and uses them whenever it can so you won’t need to wait through unnecessary source builds.

Cask: Represents a package that can’t be built from source. In practice, a Cask usually means something that ends with `.app`. Technically, Homebrew Cask is very much a separate package manager in itself. (You can tell by looking at the individual `brew cask` commands.) That’s because it caters to somewhat different use cases, and because it used to be a separate project before it went on to merge with Homebrew.

Caskroom: directory hierarchy for Cask-related bookkeeping. Caskroom is also the name of the former organization in charge of Casks; but that’s history now given all things Cask have officially become part of Homebrew.

It’s cool that MacPorts works well for you but hey, maybe try Homebrew some time to find out how you like it? (Disclosure: am one of the core maintainers.)

Save your time and soul. Just use MacPorts.