Homebrew 2.0.0 released | Hacker News Reader

Homebrew 2.0.0 released

brew.sh

240 pointsmikemcquaid107 comments

Know what annoys me about Brew? This just happened last night. I had some package that required readline 7.x; Brew uses readline 8 now. It's not possible to simply command `brew install readline@7`. It took me 30 minutes to figure out that I had to cd into the homebrew-core directory, search through github commit history to find an old commit that used readline 7, checkout that specific commit, brew install readline, checkout master again, and then pin readline.

A package manager should not make it that difficult to downgrade a package.

Otherwise -- homebrew's great.

You can also brew install with the Github URL of a formula at a specific version. That simplifies the process somewhat, but yeah, it should be much much easier than this.

Possibly my ignorance talking in terms of what you're trying to achieve, but can't you just do this?

  brew remove packagename

  brew install packagename@versionnumber --force --overwrite

I've done this with Node so I'm using 10 rather than 11.

Edit: my pet gripe with brew is the services syntax. I want to use this:

  brew services httpd restart

Not the existing syntax:

  brew services restart httpd

But in general I'm really thankful that brew exists and it's in active development.

This only works when the maintainers have decided to keep around the old version of the software, which is only done for certain popular formulae. Otherwise they get removed quite quickly from the main tap.

Ah, I see. Thanks for the clarification.

There are older versions of some, usually larger, libraries n brew, such as node@10. But those are maintained explicitly in cases where some other important package depends on them. “Node@10” is really more of a different package than name@version.

The problem with that is, using readline 7 as an example, you need to have had readline 7's image cached on your machine, or it still needs to be 'tappable' or whatever in order to do that. In this case, brew master _only_ had readline 8 available, so if you never had readline 7 installed on your machine, it was inaccessible without bothersome workarounds.

In most cases, brew just works. That's great. But it's also used primarily by developers, and I can't imagine this is an uncommon scenario.

Can't save you your 30m now but `brew extract` should make this process much easier for future.

> Usage: brew extract [options] formula tap

> Look through repository history to find the most recent version of formula and create a copy in tap/Formula/formula@version.rb. If the tap is not installed yet, attempt to install/clone the tap before continuing.

This is a poor way to handle library upgrades that are guaranteed to break any existing compiled binaries.

Frustrating that my PR to create readline@7 was rejected. https://github.com/Homebrew/homebrew-core/pull/36782

I would at least like to see some mechanism to exclude a Formula from automatic gc of old versions besides brew pin. Libraries don't take up significant space, and they cause a world of hurt to delete out from under compiled binaries, so there is not a good argument for automatically deleting them.

I would say that a package manager shouldn't break the runtime dependencies of your installed programs. That's really a poor design.

But you can also just copy the previous version into the new readline directory.

cp /usr/local/Cellar/readline/7.0.5/lib/lib*.7.dylib /usr/local/opt/readline/lib/

Although this will break with the next readline update.

That only works if you have the previous version on your machine, which we did not.

But then that package you wanted to install was not a Homebrew package?

Otherwise the dependency management in Homebrew is even worse than I knew.

this happened to me too. And since brew upgrade now also does cleanup by default, I did not have realine 7 around anymore. No information offerred on how to get it back, just wasted dev time.

I love Homebrew, especially since I (recently) realized I could use brew cask to install all my desktop applications. I liked the analytics feature in this release. Just the other day, I was looking at alternatives to official Chromium builds that would auto-update. I stumbled upon freesmug-chromium but didn't know how actively it is used by the community. Now I know.

I didn't know that was public. It's available at https://formulae.brew.sh/analytics/ for anyone curious

I tried to do that for smtg I can't remember. Turns out that it added a lot of deps and compiled the app. I didn't liked it and uninstalled it and brew kept all the deps installed.

It seems it misses an "automatically" installed flag in order to remove the deps I didn't have specifically installed myself in the first place. Would be very great for brew to have that.

Now I avoid trying new apps through brew.

An indication of the formula downloading a pre-built binary or compiling it would be nice too, btw.

> It seems it misses an "automatically" installed flag in order to remove the deps I didn't have specifically installed myself in the first place. Would be very great for brew to have that.

You can use `brew bundle dump` and `brew bundle cleanup` to achieve this (I often do the same).

Automation is great but you're opening up yourself to a security problem by hoping the manifest file is never tainted when you install or update. I can manage to install and update less than 10 non App Store apps without thinking of getting backdoored binary from slipping in at one time.

The argument over the removal of options in this thread [0] is brutal. Very intentionally user-hostile move, repeatedly disguised as being in their overall interest. It left me not feeling very good about the direction the project is taking.

[0]: https://github.com/Homebrew/homebrew-core/issues/31510

Just don't say how it's a user-hostile move and that you don't feel confident about how Homebrew development is handled, since you will be blocked from accessing the Github repositories.

Is there a more verbose explanation about why they’re moving away from compiling packages from source? All the explanations I’ve seen make it sound like that’s the obvious direction it should go, but it’s not obvious to me.

Maybe ask the question the other way around. Why should they keep compiling everything from source? What are the benefits?

You get native binaries, can choose optional features and dependencies and you can easily apply your own choice of patches. That's my view as a gentoo user anyway; I don't know how much of that homebrew actually supports.

Homebrew used to support optional features, but is now moving away from this to become a binary package manager.

What does “native binary” mean?

Compiled locally, so (posssibly) optimized for better performance than a generic binary compiled for your architecture.

Compilers like GCC can produce code specifically for your CPU such that it uses all of the special features you might have like SSE, AVX etc. When binaries are made for general use they have to be compiled with a generic feature set so might not make best use of your CPU.

So can a cross compiler, no?

If you know the exact flags for your CPU then you can compile for it on any other CPU using a cross compiler line GCC, yes. But that doesn't help because in practice you'll just find one binary per architecture, not per CPU.

At least it should no longer take a night to compile some GUI app like back in the days.

Well, for one, as a longtime brew user, changing to binary packages alters the trust model.

Binaries are built on CI infra with logs that are publicly available and with all the source code doing the builds publicly available. Effectively the same process as local, from source builds. The bottle DSL ensures that the SHA binaries are not tampered with between when they were built (and the source code sha checked) and when they are delivered.

I know this is still a different trust model, but, IMO, not too different.

I know reproducible builds are on the radar for Homebrew in the future, and that should ease some of your concerns too.

For a good thread on Homebrew security checkout https://twitter.com/c_pellegrino/status/1093195802871246848

Hey! Thanks for the reply. I’ll definitely check that link out. It’s really nice to know more about the process behind delivering binaries.

Compare to e.g. conda, where you get binary packages and no option to build from source at all. This basically means you get support for x86 and very limited support for PPC. Need ARM? Nope, no can do. Or any other slightly exotic architecture.

It also means, though this is only a problem with third party channels, that it's possible to get into a situation where you can't even build from source at all. I was working with one of our custom packages, where for the life of me I could not figure out how to get the build to work. Turns out it had been hardcoded to run on a very specific machine, and assumed access to a very specific network file system, and I wasted about a week of my life trying to untangle those assumptions before giving up. If that software had been designed from the beginning with the idea that it ought to be possible to build from source from anywhere, we'd presumably be in a different situation now.

Conda has support for armv7 via berryconda.

Interesting, good to know. I'm guessing third party channel support is probably close to nil though, so for my use case it probably wouldn't get me very far.

As a user, you can always ask for the package to be compiled from source. This is also what will happen if you ask for non-standard options. The advantage of using binary packages is time: I have a Homebrew formula that takes 40 minutes to build from source, but maybe ten seconds to install from a binary package.

Options have been deprecated, and I haven’t been able to find anything that replaces them that the maintainers are willing to discuss.

Options have been removed in the main Homebrew/homebrew-core tap but are not deprecated for user taps.

I got into a minor argument with the maintainers about it, and the response I got was that they thought it was an unreasonable support burden: https://discourse.brew.sh/t/maintaining-a-tap-to-provide-opt.... Not something I could get them to provide more details about, however. Not really a fan of the response I got :/

The actual response:

> We’re not willing to ship things we don’t support, sorry. I do not consider it acceptable to ship software that we are unable to test and we know will break. Even if I did consider that acceptable I’d be unwilling to accept the additional support burden that the maintainers have to take on from people submitting issues when they are clearly told not to (something that still happens often).

Clarification beyond that: fixing avoidable user issues is not what most of the maintainers want to spend most of their (volunteer, mostly evening and weekend) time on. Even immediately closing issues as WONTFIX takes more time to deal with than not getting an issue at all.

You may disagree with this (clearly some people do) but ultimately you cannot expect a volunteer run project to support more than they are willing to do. If we had people stepping up and saying "I will deal with all the support requests for this!" that'd be different but mostly we have people who want us to do the work for them.

In short:

- it's faster for end-users

- it's more reliable (which both makes the user experience better for users and reduces the support burden for our volunteer maintainers)

What happens to all of my packages I have installed with options? When I upgrade them next they will suddenly be stripped down? ffmpeg is a huge one, as the default set of options excludes many things that most people using ffmpeg need by default, but homebrew can't ship as a binary for legal reasons.

Yes, they get reinstalled without the options.

Wow, Linux support. I guess that's useful for those times when the OS package manager is out of date? Or is it in order to not run as root?

It’s very useful when on a remote login where you don’t have root but want more modern software e.g. academic HPC clusters with shared filesystems, which tend to have extremely “conservative” OS versions (we are stuck on RHEL6 for the forseeable future).

I’m not aware of much else that fulfills this niche well - conda seems very very tied to precisely tested version combinations, and (from what I remember - tried and had problems) nix seems to want root/system level daemons.

pkgsrc[1] is portable to most Unix(-like) systems, and can run as a non-privileged user, so that would likely work as well. I'd trust it more than homebrew anyway.

[1]: http://pkgsrc.org/

> I'd trust it more than homebrew anyway.

I'm curious why you feel this way.

> conda seems very very tied to precisely tested version combinations, and (from what I remember - tried and had problems)

Hello. Conda core contributor here. Do you have any more details? Would love to help.

We try to keep version constraints among dependencies as loose as possible. We do actively patch dependency metadata over time, putting upper version bounds on dependencies when incompatibilities eventually arise.

I wouldn't recommend it for Fedora since dnf repos are as updated as brew (if not faster) and dep version conflicts are handled better than almost any package manager out there imho.

I believe that brew makes it much easier to support multiple versions of the same package installed simultaneously.

Yes, I like Homebrew's GNU stow - like capabilities of linking stuff in and out of your environment.

A word of warning, however: Homebrew 2.0 removes your old formula from the Cellar when upgrading. If you want to disable this you must set HOMEBREW_NO_INSTALL_CLEANUP in your environment if you want to hold on to those older versions.

I wonder if it builds on Amazon's weird version of Linux they use on EC2 machines by default

Why they put stuff under /home/linuxbrew, I don't know. That practice is so unordinary, I refuse to use it.

You can put it under your home folder too. That's the primary use case, I believe: cases where the system is old & crufty and you don't have root.

Yes, many maintainers/linuxbrew folk are/were in science/academia. They were tired of logging into HPC system X and needing a certain piece of software. With linuxbrew/homebrew on linux you can just install/build the entire toolchain in user land and get software in your home directory when you don't have root.

Remember that Homebrew uses Google Analytics by default unless you explicitly disable it.

Info at https://docs.brew.sh/Analytics.

To disable it, do either of

  export HOMEBREW_NO_ANALYTICS=1

  brew analytics off

Isn't this punishable by GDPR?

IANAL but I believe no personal information is involved.

I love brew. But I have heard a lot of complaints against it, and arguments that Nix (and probably Guix) is better. I tried it once, and had a tough time getting my old scripts to find the exact versions. I gave up on Nix. Can someone eli5 why Nix-like approaches are far superior to systems like brew?

Nix is just way more reliable than Homebrew, because it does not use system tools, but rather builds the dependencies by itself (including, for example, a C compiler). Furthermore, dependencies will not be overwritten if a different package requires the same dependency, but another version of it, so packages don’t break each other.

You should not use Homebrew. The maintainers are not trustworthy.

https://chr4.org/blog/2016/04/26/homebrew-betrayed-us-all-to...

TLDR: they turned on Google Analytics.

...without consent or opt-in.

Because most other websites/services ask for consent for their analytics?

"Because everyone else does it" isn't a very good excuse.

Important consideration: homebrew is neither a website nor a service. It is a local software, a package manager, and quietly enabling phone-home analytics in an update after previously not doing such has a different threshold for “informed consent”.

How exactly is Homebrew not a service? We donate hours of work each week in an honest effort to make the best package manager we can for our users. Analytics help us decide how to prioritize our work.

It’s also literally the opposite of quietly enabled [1] [2].

[1] https://github.com/Homebrew/brew/blob/e32c1515432a938093d5ef...

[2] https://docs.brew.sh/Analytics

> How exactly is Homebrew not a service?

Is youtube-dl a service because it needs to be constantly updated, at great effort, to deal with new countermeasures and the like? Still looks like software to me.

If you were running the software for me (e.g. Gmail), then maybe Homebrew would qualify as a service.

> It’s also literally the opposite of quietly enabled

I discovered it when my firewall showed me an outbound connection to Google analytics. Homebrew spews so much stuff to the console, it's not something a regular user would read unless they looked for it. That was hardly sufficient disclosure.

You guys could have prompted for consent. You didn't. You still refuse to. And you won't entertain any suggestions that you do so unless it comes from a contributor. As I said in my original comment, your collective lack of judgement and refusal to consider the opinions of users is why I don't find you guys to be trustworthy anymore. I encourage everyone to find alternatives.

> If you were running the software for me

I’m not sure on whose systems you believe packages are built and tested, and from whose systems you feel Homebrew downloads bottles.

> it's not something a regular user would read unless they looked for it. That was hardly sufficient disclosure.

That notice was colored, it was typeset in bold, it was surrounded by newlines, and it sounded an audible bell. Blaming Homebrew for the fact that you missed that message says more about you than about Homebrew.

> I’m not sure on whose systems you believe packages are built and tested, and from whose systems you feel Homebrew downloads bottles.

Is Ubuntu a service because Canonical builds and tests packages and hosts package repositories? I don't think many people would make that claim.

> That notice was colored, it was typeset in bold, it was surrounded by newlines, and it sounded an audible bell.

That's not the notice I got.

"Anonymous aggregate user behaviour analytics documentation: https://git.io/brew-analytics". No bold. No bell.

The notice you linked to was added in reaction to the outcry. The bold and bell were added at a later date.

The Homebrew maintainers continue to refuse to do the only ethical thing and PROMPT THE USER instead of making assumptions one way or another.

So pretty much like every other website on the Internet. Got it.

I don't expect my package manager to require uBlock Origin. I actually caught it with my firewall, which was an unpleasant surprise.

Doesn't apt track installs?

Popcon in Debian and Ubuntu is opt-in. They ask you at install time whether or not you'd like to participate.

What is the best argument for anonymized tracking being malicious? I don't understand the alarm over this, and I'm a guy who has passed around Martin Fowler's great essay on privacy https://www.martinfowler.com/articles/bothersome-privacy.htm...

I don't know what Google does with those packets. Also, I've seen far too many examples of deanonymization to trust claims that data is properly anonomyzed.

When it comes down to it, principle of least privilege applies here. Homebrew doesn't need to phone home to Google to install packages, so it shouldn't.

Saying that the maintainers are untrustworthy because they take an opinion that you disagree with is uncharitable.

They opted their users in to analytics (using Google, no less) with disclosure so minimal, most users would miss it. They would not entertain any suggestion that analytics should be opt in, saying that unless you're a contributor, your opinion on the matter means nothing.

They showed a shocking lack of judgement and an abundance of arrogance. I can't trust them anymore. I don't think others should, either.

What is the best argument for anonymized tracking being malicious? I don't understand the alarm over this.

Well, I for one don't trust Mike after he forced one of the maintainers to resign and then edited his comment on Github and removed the bit where it said "because Mike forced me to resign".

Do you have a link to this? I'm curious to learn what happened here; this sounds pretty horrible…

https://github.com/Homebrew/brew/pull/4864

The comment that Mike edited is the last one. Clicking on the "edited by MikeMcQuiad" allows you to see the different versions.

…wow. I don't know what to say; this is pretty egregious. This seems like it came out-of-the-blue; why was Dominyk forced out? Because he made this pull request?

Seems like it's precisely because of that PR. Maybe Mike saw it as a mutiny. But I'm guessing that since he never explained himself in that PR, he's not going to do it at all. It's not like he's unaware of it.

I cannot fully explain this in any public forum without betraying the confidence of things that were said to me in private messages and our private Slack by other maintainers. What I can say is that I do not agree with the claim that I forced DomT4 to resign, it did not come out of the blue, this was the second time that DomT4 has decided to leave the project and all of my decisions were run past other (still active) Homebrew maintainers before I took them.

Terminology is still confusing (for no apparent reason), Homebrew is still extremely slow compared to Linux package managers.

Otherwise, I love it and it’s basically the one reason development on macOS is not a major PITA. So thank you to everyone making that possible!

I didn't know Windows support was on the roadmap. Homebrew has been a critical piece of my macOS toolkit for nearly a decade but I've been working cross-platform more lately so this could be great for me. But what about Chocolatey?

The Windows version only supports Linux apps, not native Windows apps. So it doesn't really replace Chocolatey.

Perfect timing, as I'm setting up a new box today. Homebrew is great. Also really appreciate the inclusion of reasoning behind changes in the release notes.

So far the Homebrew experience has been better for me than any other Linux distribution's package manager, except for Arch, which is still unparalleled. The biggest problem of Homebrew is how incredibly slow it is, though I guess this will stay for a long time unless a fundamental overhaul takes place.

It's a shame it still doesn't play well with more than one user on a system trying to install packages.

I have a work user and a personal user on my laptop. Brew won't let me use both at the same time without getting my hands dirty with creating groups, and even then it's not supported behaviour.

I ended up creating a homebrew user and giving my personal user sudo access to the homebrew user, which has seemed to work well so far (I may have had to give group read/execute access to all of /usr/local though)

Thanks for the tip, I didn’t think of that! I need to use Homebrew from two different users, too. Definitely going to try this.

Love this for WSL. Makes Microsoft Windows 10 even more cool!

May I ask why? Is apt not sufficient?

Think of it like a virtual env in python. You're installing within your own virtual env rather than system wide like apt.

OSX app bundle is to OSX as ____ is to Linux.

Can the blank be filled in?

If so I'd love to use Homebrew to manage dependencies on both Linux and OSX. (msys2 has my Windows build covered.)

Flatpak?

AppImage maybe

Happy about support for Linux!

I spent a year with Ubuntu MATE after over a decade of macOS use. The thing I missed the most was the hassle free installation of packages via brew. This made me very happy. I hope it will work as friction free as brew on macOS.

I don't know Ubuntu MATE specifically, and it's been a long time since I used Linux on the desktop, but I'm surprised that "apt install foo" has more friction than "brew install foo". Both work very nicely in my experience.

What is the hassle you saw with Ubuntu MATE?

Every app I use is available via brew.

A lot of software that I use weren't available via APT so I had to go hunting via snap, flatpak and pip. Suddenly I had four different package managers to maintain and update. Every time I updated Ubuntu it was a mess to update where what repositories to update to. I was never successful in keeping my software up to date without a lot of googling and problem solving and it sucked.

Someone is about to post how the original author was not hired by Google...

Original source: https://twitter.com/mxcl/status/608682016205344768

Reply on news.ycombinator.com