6 ms·

Homebrew 2.2

85 points by mikemcquaid 7y ago

exabrial 7y ago
Man I've been using Brew on Catalina for awhile, didn't realize this wasnt supposed to work!
- cassianoleal 7y ago
  Same here. Since the betas actually.
- pvinis 7y ago
  Same. What has changed to make it "support" Catalina? Edit: Found it. I didn't see I could click it. https://github.com/Homebrew/homebrew-core/issues/44988 https://github.com/Homebrew/homebrew-core/issues/44988
- teilo 7y ago
  The only reason it did work was because you did an upgrade. I was also on the betas. As an experiment, I backed up my Homebrew install and tried one from scratch. Failed badly. Very important things like gnu-readline would not compile. I couldn't even get as far as nvim. Packaging work was already being done under 2.1 to fix what was broken, and Catalina bottles were already appearing. By the time Catalina final came out, it was usable from scratch, but only if you had homebrew installed under /usr/local so you could rely on the aforementioned bottles. I was using an alternative prefix of /opt/homebrew. (I have been for years). When I attempted to continue using that, a few packages for which there were Catalina bottles would not compile, and so could not be installed under /opt/homebrew. I finally gave up, and started from scratch under /usr/local. I REALLY don't like how homebrew insists on /usr/local for stability. The whole "do yourself a favor" mentality speaks to something broken in their packaging methodology. Any package should be able to be compiled under any prefix. And for the most part they can be, except for the exceptions that the core team or package maintainer doesn't care about because "you were warned." I wouldn't mind using /usr/local were it not for the fact that lots of other installers want to put stuff there, and it can cause conflicts. Keeping homebrew in an isolated prefix makes a lot more sense. /usr/local was and remains a poor choice.
- alwillis 7y ago
  In the early days of the Catalina betas, running Homebrew would give a warning message that Catalina was unsupported, etc.
angrygoat 7y ago
Just ran an update and got this: ==> Homebrew has enabled anonymous aggregate formulae and cask analytics. Read the analytics documentation (and how to opt-out) here: https://docs.brew.sh/Analytics Opt-out analytics capture? A bit of a shame it's not opt-in. The fix is to run: brew analytics off
- laurent123456 7y ago
  This is not new, it's been around since 2016: https://github.com/Homebrew/brew/commit/1238c65ba14831bc571cf01aead8fd10b916c837#diff-bf4fb942b914c257d474cd2f921e734d https://github.com/Homebrew/brew/commit/1238c65ba14831bc571c...
  - blitmap 7y ago
    So it is user-hostile because of data collection, and that the opt-out is not preserved :-)
    - toomuchtodo 7y ago
      It's opt-in because you don't have to use brew if you don't want to. It helps the devs do their jobs better (a job they do for free), and it is a free tool someone is under no obligation to use. Previous discussion: https://news.ycombinator.com/item?id=11566720 https://news.ycombinator.com/item?id=11566720
      - saagarjha 7y ago
        Please don’t subvert the meaning of “opt-in” like this; also, mentioning “free” does not give you a pass to shut down any complaints about the software. To address your other points: I disagree that opt-in analytics necessarily help.
        toomuchtodo 7y ago
        We can disagree on both points. I'm making the effort to defend people who do real work (brew devs) vs an entitled vocal minority. Time is the ultimate non-renewable resource, and it shouldn't be wasted by grandstanders. User hostile patterns should be raised and addressed. This is not user hostile in my opinion (considering the very little data collected, and the efforts to anonymize), it is plainly obvious what data is collected, you can observe what data will be sent, you can opt out of data collection (which the devs find of value), and you can choose not to use the software. It has clearly not had an impact on usage of the tool: https://formulae.brew.sh/analytics/os-version/365d/ https://formulae.brew.sh/analytics/os-version/365d/
forgingahead 7y ago
One of the better package managers out there -- thanks to all the contributors!
xvilka 7y ago
The problem of Homebrew is the language it's written in. Porting it into something native and faster, maybe Go, maybe Rust - will make the user experience way better.
- saagarjha 7y ago
  It seems like the team has made significant improvements in speed even without changing the language Homebrew was written in; I’m sure there’s still more low-hanging fruit they can pick before having to make such a large change.
- ddavis 7y ago
  I've been using Homebrew for years and I've never felt negatively about the user experience, I find it easier to use than yum for example. What do you think can be improved?
- andrewl-hn 7y ago
  Would it, though? Almost all the time during installation is spent downloading and extracting the tarballs and running compilers if necessary. Even updating Brew itself is almost all git.
- OskarS 7y ago
  Ruby is not the problem at all. The vast majority of time with homebrew is spent doing git operations, downloading tarballs, running makefiles, and the like. You could rewrite the entire thing in Rust and not notice any difference. The thing that might make a difference is to build some custom infrastructure, so that `brew update` didn't have to do a `git fetch` every time, but instead downloaded the updated formula registry in a more efficient manner. But that's a lot to ask of a project like this.
  - Fnoord 7y ago
    > The thing that might make a difference is to build some custom infrastructure, so that `brew update` didn't have to do a `git fetch` every time, but instead downloaded the updated formula registry in a more efficient manner. But that's a lot to ask of a project like this. How would this impact privacy? If I do brew search, does that impact privacy?
tibbon 7y ago
I really wish more release documentation pointed you to how to perform that upgrade. This page, the front page, nor the installation pages show up to upgrade. No, it isn't "hard" to figure out, and I personally know how to do it, but for newer users it puts up a barrier to entry.
- saagarjha 7y ago
  I think the intent is that new users don’t really have to care about what version they’re on.
- plorkyeran 7y ago
  Homebrew updates automatically when you use it. There's nothing that the user has to do or to figure out.
Athas 7y ago
While Homebrew is perhaps technically crude and somewhat inflexible compared to other and older package managers, I think it deserves real credit for being so easy to add packages to. I contributed Homebrew packages after a few weeks of using macOS, while I didn't contribute a single package in the ten years I ran Debian. I'm also impressed by the focus of the maintainers and their willingness (really, enthusiasm) for saying no and cutting features. We need more of that in the programming field. Homebrew is unashamedly solely for running the standard configuration of the newest version of well-behaved programs, which covers at least 90% of my use cases. I use Nix when I want something complicated or nonstandard. (Incidentally, I also contributed Nix derivations after only a few weeks of running NixOS, so Homebrew is not the only good package manager.)
- chrisjc 7y ago
  What are some 'Nix derivations'? I hate to say it, but I haven't heard of any, let alone used any. edit: I guess I know lots: snappy, dpkg, apk-tools, etc... I somehow think of brew as different from this list though. I find myself often wishing that brew worked on linux.
  - aphexairlines 7y ago
    Nix derivations refers to https://nixos.org/nix/about.html https://nixos.org/nix/about.html
  - Athas 7y ago
    "Derivation" is just Nix slang for "package". I mean that I contributed some packages to the Nixpkgs collection.
  - patrec 7y ago
    Here's a concrete example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/elvis/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio... Maybe the three most noteworthy things are: 1. it's not hard to write your own nix expression 2. you get a reproducible build 3. there are very powerful hooks to allow you to easily customize derivations by various means (look at some more complex derivation, like php, which defines dozens of options and there are other mechanisms as well). 1. Brew also has, but not 2 or 3 (it's definitely more customizable than say debian packages, but much less so than nix)
fouc 7y ago
Homebrew is built on the assumption that you should always be running the latest version of homebrew and the latest version of all the packages you've installed. If something doesn't work, you're forced to update everything to the latest versions and hope that fixes things. In general I don't like this constant pressure to abandon old versions of things, it doesn't really benefit anyone. A fragmented world is a decentralized world.
- pfranz 7y ago
  I agree, but it reduces the scope of the project incredibly. Freeing up resources that can be spent elsewhere. Much like how Homebrew doesn't seem to support multiple users on the same box. It addresses 80-90% of people's need. I feel like it is less necessary for a user-land package manger like Homebrew, but doesn't Arch Linux and Gentoo do the same thing with the whole OS? I've heard of issues, but in general people seem ok with it. Personally, I've looked to Nix, but went back to Homebrew it after having trouble with the UI, lack of packages, and learning curve of contributing my own packages. I'm hoping to try again sometime.
- someonehere 7y ago
  That’s not true. You can freeze the version of binary you’re on. I haven’t had the need for it, but I remember seeing you can.
akoster 7y ago
I'm just glad Mac OS X 10.13 High Sierra and above are still fully supported since I have a computer which is stuck on that release (incompatible with 10.14).
ryenus 7y ago
TIL: > brew cat sets bat as pager if HOMEBREW_BAT is set And bat is really a nice alternative to cat.
- Pete_D 7y ago
  Huh, neat. Though I wonder why they didn't just use $PAGER.
someonehere 7y ago
Homebrew + Caskroom has made my zero touch deployments flawless. A little bash, some DEPNotify, a rock solid MDM, and Apple’s DEP, I can ship a Mac to any employee in the world and have them boot the computer, create their local account, and all of the latest third party apps get installed automatically. Ten years ago this would have taken a lot of engineering. Today it’s just bash calling Homebrew to do the heavy lifting.

Homebrew 2.2

85 points by mikemcquaid 7y ago

exabrial 7y ago

Man I've been using Brew on Catalina for awhile, didn't realize this wasnt supposed to work!

cassianoleal 7y ago
Same here. Since the betas actually.
pvinis 7y ago
Same. What has changed to make it "support" Catalina? Edit: Found it. I didn't see I could click it. https://github.com/Homebrew/homebrew-core/issues/44988 https://github.com/Homebrew/homebrew-core/issues/44988
teilo 7y ago
The only reason it did work was because you did an upgrade. I was also on the betas. As an experiment, I backed up my Homebrew install and tried one from scratch. Failed badly. Very important things like gnu-readline would not compile. I couldn't even get as far as nvim. Packaging work was already being done under 2.1 to fix what was broken, and Catalina bottles were already appearing. By the time Catalina final came out, it was usable from scratch, but only if you had homebrew installed under /usr/local so you could rely on the aforementioned bottles. I was using an alternative prefix of /opt/homebrew. (I have been for years). When I attempted to continue using that, a few packages for which there were Catalina bottles would not compile, and so could not be installed under /opt/homebrew. I finally gave up, and started from scratch under /usr/local. I REALLY don't like how homebrew insists on /usr/local for stability. The whole "do yourself a favor" mentality speaks to something broken in their packaging methodology. Any package should be able to be compiled under any prefix. And for the most part they can be, except for the exceptions that the core team or package maintainer doesn't care about because "you were warned." I wouldn't mind using /usr/local were it not for the fact that lots of other installers want to put stuff there, and it can cause conflicts. Keeping homebrew in an isolated prefix makes a lot more sense. /usr/local was and remains a poor choice.
alwillis 7y ago
In the early days of the Catalina betas, running Homebrew would give a warning message that Catalina was unsupported, etc.

angrygoat 7y ago

Just ran an update and got this: ==> Homebrew has enabled anonymous aggregate formulae and cask analytics. Read the analytics documentation (and how to opt-out) here: https://docs.brew.sh/Analytics Opt-out analytics capture? A bit of a shame it's not opt-in. The fix is to run: brew analytics off

laurent123456 7y ago
This is not new, it's been around since 2016: https://github.com/Homebrew/brew/commit/1238c65ba14831bc571cf01aead8fd10b916c837#diff-bf4fb942b914c257d474cd2f921e734d https://github.com/Homebrew/brew/commit/1238c65ba14831bc571c...
- blitmap 7y ago
  So it is user-hostile because of data collection, and that the opt-out is not preserved :-)
  - toomuchtodo 7y ago
    It's opt-in because you don't have to use brew if you don't want to. It helps the devs do their jobs better (a job they do for free), and it is a free tool someone is under no obligation to use. Previous discussion: https://news.ycombinator.com/item?id=11566720 https://news.ycombinator.com/item?id=11566720
    - saagarjha 7y ago
      Please don’t subvert the meaning of “opt-in” like this; also, mentioning “free” does not give you a pass to shut down any complaints about the software. To address your other points: I disagree that opt-in analytics necessarily help.
      - toomuchtodo 7y ago
        We can disagree on both points. I'm making the effort to defend people who do real work (brew devs) vs an entitled vocal minority. Time is the ultimate non-renewable resource, and it shouldn't be wasted by grandstanders. User hostile patterns should be raised and addressed. This is not user hostile in my opinion (considering the very little data collected, and the efforts to anonymize), it is plainly obvious what data is collected, you can observe what data will be sent, you can opt out of data collection (which the devs find of value), and you can choose not to use the software. It has clearly not had an impact on usage of the tool: https://formulae.brew.sh/analytics/os-version/365d/ https://formulae.brew.sh/analytics/os-version/365d/

forgingahead 7y ago

One of the better package managers out there -- thanks to all the contributors!

xvilka 7y ago

The problem of Homebrew is the language it's written in. Porting it into something native and faster, maybe Go, maybe Rust - will make the user experience way better.

saagarjha 7y ago
It seems like the team has made significant improvements in speed even without changing the language Homebrew was written in; I’m sure there’s still more low-hanging fruit they can pick before having to make such a large change.
ddavis 7y ago
I've been using Homebrew for years and I've never felt negatively about the user experience, I find it easier to use than yum for example. What do you think can be improved?
andrewl-hn 7y ago
Would it, though? Almost all the time during installation is spent downloading and extracting the tarballs and running compilers if necessary. Even updating Brew itself is almost all git.
OskarS 7y ago
Ruby is not the problem at all. The vast majority of time with homebrew is spent doing git operations, downloading tarballs, running makefiles, and the like. You could rewrite the entire thing in Rust and not notice any difference. The thing that might make a difference is to build some custom infrastructure, so that `brew update` didn't have to do a `git fetch` every time, but instead downloaded the updated formula registry in a more efficient manner. But that's a lot to ask of a project like this.
- Fnoord 7y ago
  > The thing that might make a difference is to build some custom infrastructure, so that `brew update` didn't have to do a `git fetch` every time, but instead downloaded the updated formula registry in a more efficient manner. But that's a lot to ask of a project like this. How would this impact privacy? If I do brew search, does that impact privacy?

tibbon 7y ago

I really wish more release documentation pointed you to how to perform that upgrade. This page, the front page, nor the installation pages show up to upgrade. No, it isn't "hard" to figure out, and I personally know how to do it, but for newer users it puts up a barrier to entry.

saagarjha 7y ago
I think the intent is that new users don’t really have to care about what version they’re on.
plorkyeran 7y ago
Homebrew updates automatically when you use it. There's nothing that the user has to do or to figure out.

Athas 7y ago

While Homebrew is perhaps technically crude and somewhat inflexible compared to other and older package managers, I think it deserves real credit for being so easy to add packages to. I contributed Homebrew packages after a few weeks of using macOS, while I didn't contribute a single package in the ten years I ran Debian. I'm also impressed by the focus of the maintainers and their willingness (really, enthusiasm) for saying no and cutting features. We need more of that in the programming field. Homebrew is unashamedly solely for running the standard configuration of the newest version of well-behaved programs, which covers at least 90% of my use cases. I use Nix when I want something complicated or nonstandard. (Incidentally, I also contributed Nix derivations after only a few weeks of running NixOS, so Homebrew is not the only good package manager.)

chrisjc 7y ago
What are some 'Nix derivations'? I hate to say it, but I haven't heard of any, let alone used any. edit: I guess I know lots: snappy, dpkg, apk-tools, etc... I somehow think of brew as different from this list though. I find myself often wishing that brew worked on linux.
- aphexairlines 7y ago
  Nix derivations refers to https://nixos.org/nix/about.html https://nixos.org/nix/about.html
- Athas 7y ago
  "Derivation" is just Nix slang for "package". I mean that I contributed some packages to the Nixpkgs collection.
- patrec 7y ago
  Here's a concrete example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/elvis/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio... Maybe the three most noteworthy things are: 1. it's not hard to write your own nix expression 2. you get a reproducible build 3. there are very powerful hooks to allow you to easily customize derivations by various means (look at some more complex derivation, like php, which defines dozens of options and there are other mechanisms as well). 1. Brew also has, but not 2 or 3 (it's definitely more customizable than say debian packages, but much less so than nix)

fouc 7y ago

Homebrew is built on the assumption that you should always be running the latest version of homebrew and the latest version of all the packages you've installed. If something doesn't work, you're forced to update everything to the latest versions and hope that fixes things. In general I don't like this constant pressure to abandon old versions of things, it doesn't really benefit anyone. A fragmented world is a decentralized world.

pfranz 7y ago
I agree, but it reduces the scope of the project incredibly. Freeing up resources that can be spent elsewhere. Much like how Homebrew doesn't seem to support multiple users on the same box. It addresses 80-90% of people's need. I feel like it is less necessary for a user-land package manger like Homebrew, but doesn't Arch Linux and Gentoo do the same thing with the whole OS? I've heard of issues, but in general people seem ok with it. Personally, I've looked to Nix, but went back to Homebrew it after having trouble with the UI, lack of packages, and learning curve of contributing my own packages. I'm hoping to try again sometime.
someonehere 7y ago
That’s not true. You can freeze the version of binary you’re on. I haven’t had the need for it, but I remember seeing you can.

akoster 7y ago

I'm just glad Mac OS X 10.13 High Sierra and above are still fully supported since I have a computer which is stuck on that release (incompatible with 10.14).

ryenus 7y ago

TIL: > brew cat sets bat as pager if HOMEBREW_BAT is set And bat is really a nice alternative to cat.

Pete_D 7y ago
Huh, neat. Though I wonder why they didn't just use $PAGER.

someonehere 7y ago

Homebrew + Caskroom has made my zero touch deployments flawless. A little bash, some DEPNotify, a rock solid MDM, and Apple’s DEP, I can ship a Mac to any employee in the world and have them boot the computer, create their local account, and all of the latest third party apps get installed automatically. Ten years ago this would have taken a lot of engineering. Today it’s just bash calling Homebrew to do the heavy lifting.