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.
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.
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.
Also, I have some tools installed with brew, that have postgres as dependency (e.g. pgloader or mapnik).
Please elaborate on the claim that "running a SQL database" is the purpose of containers.
However, if I do some exploratory experiments, where I don't care about repeability and where I use other local tools (like the mentioned mapnik, or jupyter), having it in container is needless complication.
By and large, there’s no such thing as a container, there’s just sprinkles of housekeeping magic. To wit, Docker implemented in around 100 lines of bash:
https://github.com/p8952/bocker
Problems come when we think that today’s containers manage to actually contain anything, bring any security guarantees, or do much else than just slightly-more-successfully jump start a configurable bundle of dependencies.
Why wouldn't you want to run a database under VT-x, with random emulated hardware and a dependency-bundled disk image? By and large there's no such thing as a VM, there's just sprinkles of housekeeping magic?
Containers as specced and implemented do come with security guarantees. And if they fail to meet them it's a bug.
- 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.
https://applehelpwriter.com/2018/03/21/how-homebrew-invites-...
https://askubuntu.com/questions/261326/is-it-safe-to-chown-u...
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.
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.
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.
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.
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).
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.
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.
Installing anything with brew involving multiple dependencies is also taking forever-ish, compared to mere seconds with apt.