6 ms·

Where do you see the limitations of Brew? Despite it being a little wonky on beta releases of a new macOS iteration it works fine for me.

dastx 6y ago
Last time I used a Mac was around, maybe 3 years ago, so this certainly may have improved. I had a lot of issues with Brew, but the biggest one was how slow it was. Upgrading all packages on my Mac used to take hours.
- vkoskiv 6y ago
  Still quite slow. As far as I know, it's just a big heap of small ruby scripts that invoke each other, and ruby isn't known for blazing-fast performance. It also uses git internally, and quite heavily, so that probably adds some overhead as well.
vkoskiv 6y ago
I think the main criticism of homebrew is that it's really slow.
- tokamak-teapot 6y ago
  Slow where? Searching could be faster, but it’s a few seconds. Installing is fast except where compilation happens. I have to admit I don’t know why it compiles when it does, but it isn’t all packages that get compiled.
  - varjag 6y ago
    Well, a few seconds for package search in a local index is slow. It's instantaneous with apt on my 3 year old Linux desktop, where here is the famous M1 advantage? :) Installing anything with brew involving multiple dependencies is also taking forever-ish, compared to mere seconds with apt.
  - ratww 6y ago
    It wants to update a few times a day by default when you call it, so running a simple brew install anything normally takes about 30 seconds (I'm in a MB Pro), even if it's just to say the package you want wasn't found. If you don't run it daily, it takes about a minute or two to update. But even when it doesn't update, it is extremely slow compared to any other package managers. It is disruptively slow and it takes a lot of resources, even in a powerful machine (and I'm not talking about compilation here).
    - tokamak-teapot 6y ago
      I think I’m just not used to faster package managers and I don’t install packages often enough for it to feel disruptive to wait a few seconds. I do like tools to be as fast as possible, though, and I’d forgotten about that update it does sometimes when I run it - that does seem to take a long time. I’ll have a look at how it works and see what the things are that take time. I would expect network traffic for updates, perhaps whatever it’s getting updates from does some processing (I’m sure it said something about GitHub), perhaps there is some dependency resolution that needs CPU... It would be interesting to compare its architecture to other package managers if they’re significantly faster.
      - ratww 6y ago
        The slowness is mostly due to Ruby and the git pull. I contributed in the past and reimplemented it in bash, and there isn't much going on, honestly. 99% of the time, installing a package consists of downloading a few zips from their CDN, decompressing and linking. For those cases Brew could just be checking an API instead of constantly cloning the git repository. I'm quite surprised nobody has reimplemented it in Rust or Go. The architecture is quite simple compared to a normal package manager. Maybe it's just superstition: people see "package manager" and assume it's complicated instead of digging into the code and finding out how it works.
- sonu27 6y ago
  It also has a fair share of problems. Like multiple users on the same machine, I had issues with permissions, etc
mark_l_watson 6y ago
I second that. On my M1 MacBook Pro, I have both the M1 version and Intel versions installed. I have found that if I use the Intel installation to install something like MIT-Scheme in a terminal running Rosetta, the it is available everywhere. It took me a little while to get that sorted out.
SahAssar 6y ago
It's been argued that the recommended way it works is a security issue: https://applehelpwriter.com/2018/03/21/how-homebrew-invites-users-to-get-pwned/ https://applehelpwriter.com/2018/03/21/how-homebrew-invites-... https://askubuntu.com/questions/261326/is-it-safe-to-chown-usr-local https://askubuntu.com/questions/261326/is-it-safe-to-chown-u...
- tobylane 6y ago
  On Apple Silicon it now installs to /opt/homebrew, a change they’ve been wanting to do for a while.
  - matthewbauer 6y ago
    Does /opt/homebrew still end up in root’s PATH, I wonder? That has the same issue that /usr/local has I think. Letting users mess with root’s environment basically means there is no real distinction between root and non-root.
    - mikemcquaid 6y ago
      No, it doesn’t.
- Hackbraten 6y ago
  It’s not really insecure. See: https://security.stackexchange.com/q/187502 https://security.stackexchange.com/q/187502
cactus2093 6y ago
It’s been a little while since I relied on it heavily, but you still can’t install/pin specific versions, right? That’s a huge limitation if you want to do any reliable development on macOS directly without using a vm or docker. It’s also just so slow to update if it’s been more than like an hour since you last updated, the way it uses one big git repo under the hood is just chaos.
- strokirk 6y ago
  Can you pin versions in apt? Last time I checked it involved a lot of work and swearing, but that might have improved lately.
  - andoriyu 6y ago
    Not really, it was pretty verbose, but wasn't hard. Pinning is for setting package priority between multiple repos. What you're looking apt is apt-holding: apt-mark hold libxfont1 That been around since 2013 IIRC. And there was dpkg way of doing it before.
- jameshart 6y ago
  You can pin versions in brew (brew pin <package>) to prevent upgrades. You can install specific versions, but it requires some gitfu - you need to uninstall, find the brew commit where the package is at the version you want, then install from that specific git blob.
vetinari 6y ago
As others mentioned (it is slow, has problem with multiple users, cannot pin versions) it is also missing features the linux distribution have. For example, you cannot have Provides: alternatives as rpm/dpkg do, you must use packages for resolving dependencies as they are provided by upstream. For example, when postgresql 12 was released, it took some months to appear in brew. Meanwhile you could not use alternate taps to resolve dependencies, if some package required postgres, it had to be the original one.
- iamAy0 6y ago
  Why would you install postgres through Brew though? Those times are way gone, that's the purpose of containers. I've been using Brew for a while to just install "core" packages like python, curl, wget and such, and everything else like a postgres, nginx, whatever..a go to a container.
  - vetinari 6y ago
    Because if you need to ingest some data, it is much slower with Docker Desktop for Mac :/ Also, I have some tools installed with brew, that have postgres as dependency (e.g. pgloader or mapnik).
  - michaelcampbell 6y ago
    Not going to wade into the "should" or "shouldn't" of this, but I have used postgres-via-docker for ... few years now, and it is a DREAM. And I never have to worry about versions or dependencies (at least I haven't yet).
    - earthboundkid 6y ago
      I've installed Postgres on my Mac with Homebrew, Docker, and https://postgresapp.com https://postgresapp.com. There are arguments for each of them. On the pro side: - Homebrew is a general purpose package manager, and Postgres is a package you might want managed. - If you're using Docker/Docker Compose for a project anyway, that's the obvious way to do it. - Postgres.app is a specialized tool just for managing Postgres installs, so it's hard to beat if that's what you need. Some thoughts on the tradeoffs though: - Homebrew really doesn't like the idea of "versions". It wants everything to be on the latest. That can be fine if you just need a tool locally, but if you want dev and prod to match, it is a pain in the ass. - Docker isn't really very good at persistence. That's probably not a problem for local development, but you should be aware of it. Running it on a Mac introduces speed and memory issues you wouldn't otherwise have. And now obviously there's the M1 problem. - Postgres.app is another thing to install. If you just need Postgres for one particular project you might not know about it or want to deal with installing something new.

dastx 6y ago

Last time I used a Mac was around, maybe 3 years ago, so this certainly may have improved. I had a lot of issues with Brew, but the biggest one was how slow it was. Upgrading all packages on my Mac used to take hours.

vkoskiv 6y ago
Still quite slow. As far as I know, it's just a big heap of small ruby scripts that invoke each other, and ruby isn't known for blazing-fast performance. It also uses git internally, and quite heavily, so that probably adds some overhead as well.

vkoskiv 6y ago

I think the main criticism of homebrew is that it's really slow.

tokamak-teapot 6y ago
Slow where? Searching could be faster, but it’s a few seconds. Installing is fast except where compilation happens. I have to admit I don’t know why it compiles when it does, but it isn’t all packages that get compiled.
- varjag 6y ago
  Well, a few seconds for package search in a local index is slow. It's instantaneous with apt on my 3 year old Linux desktop, where here is the famous M1 advantage? :) Installing anything with brew involving multiple dependencies is also taking forever-ish, compared to mere seconds with apt.
- ratww 6y ago
  It wants to update a few times a day by default when you call it, so running a simple brew install anything normally takes about 30 seconds (I'm in a MB Pro), even if it's just to say the package you want wasn't found. If you don't run it daily, it takes about a minute or two to update. But even when it doesn't update, it is extremely slow compared to any other package managers. It is disruptively slow and it takes a lot of resources, even in a powerful machine (and I'm not talking about compilation here).
  - tokamak-teapot 6y ago
    I think I’m just not used to faster package managers and I don’t install packages often enough for it to feel disruptive to wait a few seconds. I do like tools to be as fast as possible, though, and I’d forgotten about that update it does sometimes when I run it - that does seem to take a long time. I’ll have a look at how it works and see what the things are that take time. I would expect network traffic for updates, perhaps whatever it’s getting updates from does some processing (I’m sure it said something about GitHub), perhaps there is some dependency resolution that needs CPU... It would be interesting to compare its architecture to other package managers if they’re significantly faster.
    - ratww 6y ago
      The slowness is mostly due to Ruby and the git pull. I contributed in the past and reimplemented it in bash, and there isn't much going on, honestly. 99% of the time, installing a package consists of downloading a few zips from their CDN, decompressing and linking. For those cases Brew could just be checking an API instead of constantly cloning the git repository. I'm quite surprised nobody has reimplemented it in Rust or Go. The architecture is quite simple compared to a normal package manager. Maybe it's just superstition: people see "package manager" and assume it's complicated instead of digging into the code and finding out how it works.
sonu27 6y ago
It also has a fair share of problems. Like multiple users on the same machine, I had issues with permissions, etc

mark_l_watson 6y ago

I second that. On my M1 MacBook Pro, I have both the M1 version and Intel versions installed. I have found that if I use the Intel installation to install something like MIT-Scheme in a terminal running Rosetta, the it is available everywhere. It took me a little while to get that sorted out.

SahAssar 6y ago

It's been argued that the recommended way it works is a security issue: https://applehelpwriter.com/2018/03/21/how-homebrew-invites-users-to-get-pwned/ https://applehelpwriter.com/2018/03/21/how-homebrew-invites-... https://askubuntu.com/questions/261326/is-it-safe-to-chown-usr-local https://askubuntu.com/questions/261326/is-it-safe-to-chown-u...

tobylane 6y ago
On Apple Silicon it now installs to /opt/homebrew, a change they’ve been wanting to do for a while.
- matthewbauer 6y ago
  Does /opt/homebrew still end up in root’s PATH, I wonder? That has the same issue that /usr/local has I think. Letting users mess with root’s environment basically means there is no real distinction between root and non-root.
  - mikemcquaid 6y ago
    No, it doesn’t.
Hackbraten 6y ago
It’s not really insecure. See: https://security.stackexchange.com/q/187502 https://security.stackexchange.com/q/187502

cactus2093 6y ago

It’s been a little while since I relied on it heavily, but you still can’t install/pin specific versions, right? That’s a huge limitation if you want to do any reliable development on macOS directly without using a vm or docker. It’s also just so slow to update if it’s been more than like an hour since you last updated, the way it uses one big git repo under the hood is just chaos.

strokirk 6y ago
Can you pin versions in apt? Last time I checked it involved a lot of work and swearing, but that might have improved lately.
- andoriyu 6y ago
  Not really, it was pretty verbose, but wasn't hard. Pinning is for setting package priority between multiple repos. What you're looking apt is apt-holding: apt-mark hold libxfont1 That been around since 2013 IIRC. And there was dpkg way of doing it before.
jameshart 6y ago
You can pin versions in brew (brew pin <package>) to prevent upgrades. You can install specific versions, but it requires some gitfu - you need to uninstall, find the brew commit where the package is at the version you want, then install from that specific git blob.

vetinari 6y ago

As others mentioned (it is slow, has problem with multiple users, cannot pin versions) it is also missing features the linux distribution have. For example, you cannot have Provides: alternatives as rpm/dpkg do, you must use packages for resolving dependencies as they are provided by upstream. For example, when postgresql 12 was released, it took some months to appear in brew. Meanwhile you could not use alternate taps to resolve dependencies, if some package required postgres, it had to be the original one.

iamAy0 6y ago
Why would you install postgres through Brew though? Those times are way gone, that's the purpose of containers. I've been using Brew for a while to just install "core" packages like python, curl, wget and such, and everything else like a postgres, nginx, whatever..a go to a container.
- vetinari 6y ago
  Because if you need to ingest some data, it is much slower with Docker Desktop for Mac :/ Also, I have some tools installed with brew, that have postgres as dependency (e.g. pgloader or mapnik).
- michaelcampbell 6y ago
  Not going to wade into the "should" or "shouldn't" of this, but I have used postgres-via-docker for ... few years now, and it is a DREAM. And I never have to worry about versions or dependencies (at least I haven't yet).
  - earthboundkid 6y ago
    I've installed Postgres on my Mac with Homebrew, Docker, and https://postgresapp.com https://postgresapp.com. There are arguments for each of them. On the pro side: - Homebrew is a general purpose package manager, and Postgres is a package you might want managed. - If you're using Docker/Docker Compose for a project anyway, that's the obvious way to do it. - Postgres.app is a specialized tool just for managing Postgres installs, so it's hard to beat if that's what you need. Some thoughts on the tradeoffs though: - Homebrew really doesn't like the idea of "versions". It wants everything to be on the latest. That can be fine if you just need a tool locally, but if you want dev and prod to match, it is a pain in the ass. - Docker isn't really very good at persistence. That's probably not a problem for local development, but you should be aware of it. Running it on a Mac introduces speed and memory issues you wouldn't otherwise have. And now obviously there's the M1 problem. - Postgres.app is another thing to install. If you just need Postgres for one particular project you might not know about it or want to deal with installing something new.