as far as cli utilities go the ux of homebrew has always been so easy to use, honestly kind of a personal benchmark for me on how repeatedly approachable it is, all commands are for whatever reason so painless to remember. i remember when apple silicon dropped and you guys followed shortly with support and the ability to switch arches, like really killer stuff so impressed with homebrew! always a treat when something im interested in tinkering with has a homebrew formula available
I saw a tweet by someone many years ago before I knew Homebrew was a thing. The tweet basically said "Google rejected me for not being able to invert a binary tree when 80% of Google engg use Homebrew"
Was that true?
Unfortunately, Max still clings to having created Homebrew as his greatest achievement, despite being so uninvolved for so long that just about the only thing that remains of his is the name and the beer nomenclature often confusing for newcomers. Since then, he’s been aggressively chasing whatever is popular at the time. When blockchain was all the rage, the made a package manager that leveraged it. Now he’s into AI stuff. But always, still at the top of his website and plastered everywhere whenever he pursues a project, he mentions he created Homebrew.
Seventeen mentions of Homebrew on the homepage alone.
So much repetition. I'm guessing it's targeting AI training sets? The guy really wants you to know he created Homebrew!
Most Linux package managers cannot separate user-installed packages from system packages. This makes cleaning up your workstation nearly impossible and a pain in the ass, since you can't tell what should be removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew, meaning you often only get outdated packages.
And because of pinning versions to LTS releases on certain Linux distributions many times those packages stay out of date for years. Which is quite annoying.
It's also quite stable, which you'd think more people would prize given the recent and on-going supply chain attacks.
Stable can also mean "you get to keep all the bugs present in this version for the next 4+ years"
VirtualBox is really bad about this.
Most popular GUI stuff is from universe, as are quite a few dev tools. Some examples: Gimp, Inkscape, pip (and a ton of python packages), most of gnome, a big chunk of KDE, htop, mariadb, etc.
See for yourself grep -h "^Package:" /var/lib/apt/lists/_universe__Packages | awk '{print $2}' | sort -u
Or to see only what you have installed from Universe: comm -12 <(dpkg-query -f '${Package}\n' -W | sort) <(grep -h "^Package:" /var/lib/apt/lists/_universe__Packages | awk '{print $2}' | sort -u)
A big repo isn't always better.
All LTS distros fix only some core packages sporadically as no one is able to back port all the patches esp. since most packages do not use CVEs and just fix bugs on the go. "Stable" for non-rolling distributions simply means "horribly broken and outdated".
I don't know where this sense of "stable" in the community comes from. Software isn't perfect and gets fixed all the time. Yes, there are packages with different maintained stable branches that you can pin for your LTS distribution but this is by far the minority. For the other stuff you constantly have to work around missing features or existing bugs. E.g., why do I have to compile "jq" by myself just because the outdated package crashes on certain inputs?!
What is the use case when someone would want to differentiate system/user installed package? Isn't it good things that they are the same - meaning once something is install - it is there regardless of how it got here.
1. It's very common, especially in certain ecosystems like Python, for the system to depend on old versions of things in such a way that updating to modern versions will break your entire system, while at the same time you want to run something at the user level that depends on a newer version. The solutions to this are usually ecosystem specific and often annoying to use for someone who just wants to run a program (again a great example being Python venvs, which at this point have decades of tooling built up around trying to make it less annoying to deal with).
2. For "cattle" systems having everything installed at the system level is generally not too much of an issue, but for "pet" systems where the user might be experimenting with things it's really nice to be able to install stuff in a way that doesn't affect anything outside of your user account even if it's also available at the system level. The computers that I personally operate from on a daily basis tend to build up a lot of crap I used once over time and removing it without just backing up my stuff and nuking it all can be a major pain.
It's worked for me since workstations were shaped like pizza boxes.
I'm sure there are some things it can't do, but it goes a long way. When you're installing distributed binary packages you have less ability to control the baked-in install dirs, but if the package honors the conventional $(env) it can work.
Mixing user and system software is like having Photoshop and all of your games install their files directly into the Windows directory.
...or not, and this is why HomeBrew exists and I need to learn it or ansible/etc.
comm -23 <(apt-mark showmanual | sort -u) <(gzip -dc /var/log/installer/initial-status.gz | sed -n 's/^Package: //p' | sort -u)
Funnily Mise does not support dependencies, and I was quite surprised that it mostly doesn't matter, as either pnpm/uv handles that, or it's a static binary that just works. In the past, had the unfortunate experience of packaging a Python application for Homebrew (the ridiculous process involved importing around 50 dependencies as "resources", building every single one from source or manually checking if it's already on Homebrew, declaring build toolchains for 5 different programming languages as dependencies, waiting over an hour for CI to finish on every update, then an upstream update introduced a "build-time dependency loop" and the project suddenly became unpackable for Homebrew) so I totally get why Mise took the "easy way out" and just relies on language-specific package managers directly.
Only thing from my Brewfile that I couldn't replace was the Docker CLI (needed to interact with Colima). And I still use Homebrew for casks. I encourage others to experiment with their dev setups, there are some amazing new tools out there.
This is intentional as mise is not intended to be a full bootstrapping solution in the way homebrew/nix is, mise is designed to be an overlay on top of existing systems. So if you want to manage python with brew and black with mise it basically just works without extra configuration. I think this design decision has paid off in spades. It sounds like a drawback but at the end of the day it's probably the #1 reason users find mise easy to use.
I tried to use it for system wide things, but found it didn't work as well for me with things that I wanted to just be tools where I didn't care what specific version it was as long as it was more or less current, Helix, NeoVim, RipGrep, etc.
I recently found mise and have become a fan as well. I have used asdf for about a decade and it supports the same .tool-versions files so initially I used it for those exact same things.
But I use four different computers for development regularly and sometimes use Codespaces as well. While syncing dotfiles handles most of my setup, it doesn't handle binary dependencies of my dotfiles - my neovim setup wants fd & rg etc. So now those go in the mise global config. I also have a global node & python along with uv@latest which pretty much covers every tool I might want to install.
I have never cared for the fact that homebrew tries to maintain shared dependencies and several upgrades have broken stuff for me.
The big drawback: having Claude complain every couple of hours that the new worktree is untrusted; or having to prefix a bunch of commands with `mise exec …` is annoying as well. A global alias for all shells would be nice.
I use Claude on a mise-powered project daily without any issues
But it's not "it just works" yet.
Also using brew for casks, and I think there’s a couple tools I couldn’t install with mise (e.g. pngpaste and zbar for scanning QR codes from screenshots).
Zbar seems to provide prebuilt binaries here https://linuxtv.org/downloads/zbar/binaries/ (haven't checked it myself)
Thanks for the docker tip!
Neat! Got curious if you can do that without a temp file, turns out you can:
#!/usr/bin/osascript -l JavaScript
ObjC.import("AppKit");
$.NSFileHandle.fileHandleWithStandardOutput.writeData(
$.NSPasteboard.generalPasteboard.dataForType("public.png"),
);
Edit:
> `docker compose` is a bit trickier
I’ve tweaked my setup a bit. This installs it as `docker-compose` without symlinking required:
"github:docker/compose" = { version = "latest", rename_exe = "docker-compose" }
DOCKER_CONFIG="${DOCKER_CONFIG:-$HOME/.docker}"
mkdir -p "${DOCKER_CONFIG}/cli-plugins"
ln -s "$(mise which docker-compose)" "${DOCKER_CONFIG}/cli-plugins/docker-compose"Projects then have their own dependencies, e.g. https://github.com/i-am-bee/agentstack/blob/main/mise.toml
Mise also has a task runner which automatically uses correct tools. Onboarding a new team member is super easy now, they just need Mise, "mise install" and they're up.
mise use -g somepackage --pin
mise up -il
It's all fairly well documented here: https://mise.jdx.dev/dev-tools/backends/
pypi, npm, and even github (through releases) are registries.
curl | sh is an anti-pattern. It passes no security check.
curl https://mise.run | sh
...which is the same way Homebrew is installed too.
Or am I missing something..?
Just downvote and move on.
We are not many [1], but Homebrew has been a great way to quickly bootstrap an environment in immutable Linux distributions.
Note that certain operating systems such as Universal Blue's Bazzite (1.28%), Bluefin (0.49%) and Aurora (0.28%) default to bundling Homebrew [2].
For example, there might be layers for “system” (core components), “environment” (display manager, DE, etc), and “user”, each of which are maintained fully separately so they can’t ever step on each others’ toes and break things. Yes, it means there will be some redundancy but for all the trouble and complexity it’s saving I think it’s a worthwhile tradeoff.
I've since moved my desktop box to NixOS, where everything is just flakes, but my mac runs circles around it so it's just there for Steam nowadays.
To be sure it is ridiculous, but it is also traditional.
This has gotten better in recent years with user namespaces but it takes time for it to be adopted and achieve parity with what used to be just jumping to a user who can only write to a newly created dir in tmp.
echo "deb [signed-by=/etc/apt/keyrings/packages.mozilla.org.asc] https://packages.mozilla.org/apt mozilla main" | sudo tee -a /etc/apt/sources.list.d/mozilla.list > /dev/null
# 1. Install our official public software signing key:
wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg; cat signal-desktop-keyring.gpg | sudo tee /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
# 2. Add our repository to your list of repositories:
wget -O signal-desktop.sources https://updates.signal.org/static/desktop/apt/signal-desktop.sources; cat signal-desktop.sources | sudo tee /etc/apt/sources.list.d/signal-desktop.sources > /dev/null
# 3. Update your package database and install Signal:
sudo apt update && sudo apt install signal-desktop
When using it without a PPA (just giving in the repo URL) it won't add the key by default, so you have to follow it up with the wget -qO- https:/mykey.asc | sudo apt-key add - (<< don't to this, apt-key add will add the key to the global trust)
early days apt-add-repository also didn't support signed-by for the signing keys. Very early on when you added some PPA, it'd add the repo's GPG key to the global keyring, so you were better off not using it anyway.
> The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago.
Each one uses their own package manager right?
What I hate is that e. g. debian puts me to conform to their FHS. I want things installed into versioned AppDirs. GoboLinux allows that; NixOS to some extent too (though they used hashed directory names). Debian does not allow me to do that. I don't want to conform to what others wrote; I want software that adjusts to my wants.
> Flatpak is more oriented towards GUI apps
Have they not recently added a mandatory systemd dependency? I can't use software that things it must force software I don't need or use onto me.
I donate to a lot of open source projects that I benefit from, but I’ve never really thought about Homebrew. I will get onto it.
And we all know how MacPorts failed to actually gain any significant momentum.
And it was first hosted at OpenDarwin — which was Apple-run and not available for arbitrary public hosting.
It was then hosted at OpenDarwin’s successor — Mac OS Forge. That was also Apple-run and not available for arbitrary project hosting.
MacPorts was an Apple-authored and ultimately Apple-supported project for ~15 years.
As for momentum, the project is still going strong 25 years later, so I’m not really sure what you’re referring to.
I am referring to a significant momentum. You know, like the momentum Brew has.
The only people I want to trust to quickly ship new code to my machine are Apple and my browser (which handles more untrusted input than anything else).
For everything else (vscode and its extensions, npm, homebrew, and all the apps that self-update), I prefer to err on the side of waiting a few days.
Some exceptional 0days might warrant a cooldown bypass, but even in its current form users are vulnerable to 0days until they run brew upgrade.
Also, where we package things from NPM/PyPi/RubyGems that have been subject to these attacks: we already apply cooldowns for you both when packaging and when creating PRs to update to new versions.
Relevant parts for those who have cool-downs at the top of mind:
> Across Homebrew’s history far more users have been protected by shipping zero-day fixes quickly than have been exposed to npm-style token-theft or crypto-mining attacks, so a global cooldown would be a net negative for most users’ security. The deeper reason Homebrew does not need a general cooldown is that, unlike language package managers, it already separates publishing from distribution: an upstream release does not reach users until it has passed human review, CI and checksum verification, which is the very review window that language-ecosystem cooldowns are trying to recreate.
[...]
> For ecosystems with a track record of fast-moving supply-side attacks, Homebrew applies a download cooldown: a freshly-published upstream version is not adopted immediately, giving the wider community time to detect and report a malicious release before Homebrew users are exposed. Cooldowns have been added for:
Bundler
RubyGems livecheck
npm and pip defaults
PyPI resource resolution
npm and PyPI in bump[1]: "Cool down before you install: give new gems a few days to be vetted" - https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-b...
Your doc says "Human review of each release." What does that actually entail?
uv had a release at 10:21am yesterday with 7,060 additions and 2,409 deletions. The new release was available in homebrew at 11:46am. What human review happened there?
I don't know of any other OS package manager that ships code this quickly to users. Arch Linux has not pushed the new release of uv yet, for example.
If the ask is "who reviewed the diff": yes, a human didn't do that. That's not actually happening for all packages in any meaningful large ecosystem. I'm still unconvinced a cooldown solves that until e.g. we have an open source security scanner that runs on all Homebrew packages and requires a cooldown. Even in that case, my suggestion would be that we just run it in our own CI and block package release.
I agree.
> open source security scanner that runs on all Homebrew packages and requires a cooldown.
I think that is where all this is going in the longterm.
Until then, any upstream shenanigans are more likely to surface in hours 0-48 after a new release than hours 0-4.
For those who don't know what broxit is talking about, they're referring to something like --minimum-release-age/minimumReleaseAge in many pieces of software and package managers to reduce vulnerability to supply chain attacks. Often times, such attacks are detected within a few days of compromise.
Here's Bun's, as an example: https://bun.com/docs/pm/cli/install#minimum-release-age
It annoyed me this week because I only had a few minutes to try elixir 1.20 after the announcement, and brew lagged behind. You can install erl and elixir by other means (I prefer to run my own toolchains) but it wasn’t worth doing in that moment.
Brew has or used to have a source option for some recipes and that basicallllly solves it too, if you squint.
> Cooldowns, livecheck and bumping
I used that for a package my company publishes, and neither we nor any other human AFAIK ever manually update it in homebrew, yet the newest version is always installable there.
- Brew seems to have better support for the packages it has, compared to Nix where it seems a percentage of packages are not as well maintained,
- Better Mac support; some Nix packages have features disabled on macOS, I think just because the maintainers of this packages don’t have a Mac for testing,
- Better UX.
Obviously I miss the reproducibility of Nix environments and the ability to easily create my own flakes with specific packages, but on the balance, Brew has won me back. (I still like Nix, and FWIW we use Nix at work.)
May I ask for what do you use it at work? I have a few places I think nix might suit but I can’t really put my finger on it.
We use Nix at work for all sorts of stuff. Binaries run in production from Nix paths. Software we build has dependencies in Nix. People on workstations run commands from Nix paths. The OS is not Nix, but the Nix package manager looks like it’s on its way to consuming most of our dependencies. It is not used for building or deploying our code, though.
Of course, I've also made a concerted effort over the years to migrate everything to uv for Python, pnpm for nodejs, etc. so maybe it's not an issue for me anymore?
For others still using Homebrew: a lot of work has gone into upgrading only when we absolutely have to and showing these upgrades to the user before we do them, including in this release.
thanks for all your work!
Now I install far more packages via devbox (or devbox global) than I do via HomeBrew (on osx) or pacman (on arch).
https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
I know supporting Intel is an ordeal and a choice, but I'm firmly on the camp that Homebrew should find a way to maintain Intel support as long as possible.
If only Apple put a fraction of its resources towards maintaining something like homebrew (or paying the people who do), maybe the situation would be different.
That’s not to say you’re crazy or anything. You do you. But do understand that you almost certainly constitute a nearly irrelevant minority of users of homebrew.
Intel homebrew is larger than Linuxbrew, yet I think it'd be shocking if they dropped support for Linuxbrew.
Old machines still work. They're still deeply useful. I'm still using daily an Intel Macbook with homebrew on it. When I no longer use it daily in some years more, it'll still make a perfect server.
If you want Intel support, MacPorts still runs back to Leopard.
Homebrew will still work (increasingly poorly) on macOS Intel for a year after that, it just won’t be “supported” or tested in CI environments (where currently macOS Intel usually slows down the release of lots of software for all other platforms).
That a volunteer run project with no employees is unable to come anywhere near the support levels of the world’s second biggest, trillion dollar company should not be surprise.
We’re also limited that GitHub (part of Microsoft, 4th biggest, also trillion dollar company) will have killed all macOS Intel CI by autumn/fall 2027 too.
We are announcing this well in advance to give people migration paths to MacPorts or other hardware.
There’s nothing stopping you for doing the work to setup “Intelbrew” and support it for the community. When I started work on Homebrew it had no funding or CI or binary packages/bottles at all. I did much of that work myself. It was hard but you could do the same.
Completely reasonable to say “I don’t have time!” but: then you need to accept the decisions of those that do, sorry.
From people who haven’t disabled analytics.
On another note, to commenters here, I've been using brew bundle with the Brewfile more and more these days as a declarative list of all user packages installed, should I just move to Mise or Nix instead? What are the benefits and drawbacks? Last time I used Nix on my MacBook a few years ago it seemed to brick my whole system so not sure what that was about.
eg I manage my Brewfile declaratively with home-manager, and then run this on file change
HOMEBREW_NO_UPDATE_REPORT_NEW=1 HOMEBREW_NO_AUTO_UPDATE=1 brew bundle --file="$HOME/Brewfile" --cleanup --no-upgradeAlso coming from what I consider traditional package managers such as apt, rpm, emerge, pkg, etc. I am still confused on cans, taps, kegs, formulas, etc. Does anyone have a good and concise guide to what all these features are?
I'd personally love a "Homebrew light", compatible with most of the ecosystem (sans git taps, Ruby formulas and binary packages), written in a language with fast startup times, not keeping unnecessary files on disk, with support for parallel downloads, and terminology that is much easier for the newcomers to remember and keep straight.
I review AI written code on Homebrew the same way I review code from a no avatar GitHub user with no previous contributions.
The experimental and abandoned brew-rs frontend was more “vibe coded” using my knowledge of how to benchmark and test homebrew accurately and with a shitload of manual testing. Maybe that’s why the performance wasn’t as good as expected, who knows.
Most Linux package managers cannot separate user-installed packages from system packages. This makes cleaning up your workstation nearly impossible and a pain in the ass, since you can't tell what should be removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew, meaning you often only get outdated packages.
Isn't that what dependency detection does? Whenever I'm not sure if something can be removed, I just try to remove it, and if it would break something else, the package manager tells me. I can broaden my scope and see if that's also an unnecessary dependency for something and follow the chain, with it eventually ending up with a set of packages where I actually get the prompt to proceed or not (meaning nothing in it is a required dependency for anything remaining), or I see a package I definitely want to keep around and stop. If I'm interested in what's part of the base system, I just check the metapackage for the base system.
This doesn't sound like something that's a problem with package managers in general compared to maybe some distros just using them poorly.
Did I miss the memo?
Forced upgrades are not nice.
I'd consider donating, but I find that behavior to be part of squeezing free computing and participating in and advocating for the corporate erosion of ownership of one's hardware environment.
I just threw them a small donation for supporting this software for so long, even if it's only 98% how I'd want the project to be run all these years myself.
Your signing point is not accurate. It doesn’t apply to all packages, only casks in the official tap. With casks the trust model, particularly on things that auto-update and don’t expose versions or checksums on download URLs, heavily relies on Apple’s security guardrails. We pushed against them for a while but Apple’s direction of travel made it clear that it was a waste of our energy and that we were at risk of compromising our users through doing so.
You can still automatically remove quarantine in third-party taps as desired, we’re just making it less easy to do so because we consider it a security feature that should require a deliberate bypass.
I don’t think anyone is obliged to donate to Homebrew but this sort of framing, assuming you use Homebrew, isn’t great. If you find what we do morally distasteful: go use something else. MacPorts, Mise and Nix are all good. This will be better for everyone than using us begrudgingly.
How many more supply chain attacks will it take for someone to build a really great sandboxing/permissioning system, that's easy enough to use that we actually use it?
Say I install an `ls` alternative (because it's on the HN front page as 'ls but in lang du jour' or whatever) – it should be really simple for me to allow it read-only access to only the passed directory. I don't think firejail or apparmour even supports that, and it'd probably take me half a day to figure it out in bubblewrap.
I just want a mobile-OS style pop-up the first time programs try to do something for me to deny, approve always, approve this time, approve by dir, or custom thing matching on the args.
I install homebrew as a first thing on my corporate amazon linux too as many system packages are lacking, and I couldn't get neovim in a different way.
I noticed that homebrew updated _all_ my casks when running 'brew upgrade' (even those with "auto_updates: true" in their Cask JSON API).
Is this intended, new default behavior? This did not use to happen...
See also: https://docs.brew.sh/FAQ#why-arent-some-apps-included-during...
I read this as "This means if you close your eyes you don’t see things, which is a bummer."
When you instruct the system not to tell you things, the system not telling you those things is a bummer?
If I could get more of the tech I interact with to stop doing things I didn't ask it to, it would reduce a lot of stress and wasted time.
I just ran the upgrade to 6.0.0, and it downloaded so many things concurrently that it killed my wifi (old router). Is there a way to cap bandwidth or maximum concurrent connections? (this is something I have to do in many download heavy apps, e.g., steam)
HOMEBREW_DOWNLOAD_CONCURRENCY
I'd use it today on Linux, but I'm pretty anal about only using software from the distribution repos (or compiled locally if not available.)
Speaking of important things.
Fantastic work Mike and team, though I’m still a little confused about cask upgrades.
It's probably discussed somewhere but didn't find when glancing at the OP.
Assuming I have already installed something homebrew 6 would not let install, will I get a warning?
I discovered Homebrew now sometimes asks whether I actually want to install a formula (e.g. `brew install ffmpeg` asks whether I want to install it because it has dependencies). Is there a way to disable this behavior and revert to the previous one?
—-no-ask, —-yes, -y or HOMEBREW_NO_ASK=1
https://github.com/Frizlab/frizlabs-conf/blob/663e287eadadd9...
Since everybody runs their own unique permutation of apt or dnf packages, adding as little as possible will keep you as close as possible to what distro maintainers test. There's even OSes like Fedora Silverblue or Bluefin or SteamOS that ship with a fully baked _image_ - where installing system level packages is strongly discouraged - which helps ensure predictability and stable upgradeability.
Homebrew packages also tend to be more recent (this depends on your distro of course) and don't require elevated permissions to install.
[1]: Other unprivileged package managers like Mise or Nix do the same of course
Honestly, I would settle for a custom prefix if it tells me exactly what packages will break and what won’t without having to read each and every formula recipe. That’s one thing that bothered me for a while and I did not have the willpower to explore that direction without having community support.
But can you please support old Mac too? As you upgrade brew, many brew break for old Mac since the old library/framework. And in this situation, i had to switch from brew to macports plus brew. It's a pain for old Mac to using brew.
MacPorts is a better fit for older hardware.
Adding package to homebrew is straightforward, except that it has a lot of (reasonable?) requirements to make it right. Basically, you make a PR with a "formula" to their main repo from your branch. Formulas are ruby programs. LLM can do it easily, and such code is accepted if correct.
Apple could’ve made something like this, or at least pay you handsomely for making Macs better to use.
Also, what about installation directories? I always install homebrew to ~/.brew since I know I’ll always have access to my home directory without sudo.
- `formula@version` packages
- `brew version-install` (which uses `brew extract` and `brew tap-new` under the hood)
- `version_file:` support in `brew bundle
- `brew pyenv-sync`
I don't understand how devs don't use a tool that makes multiple versions of everything possible.
Claude found evidence of an exfiltration malware on my laptop and I inmediately wiped the device and started again. Revoked all my keys, rotated all my passwords. And now I pray the damage is contained.
I can’t believe that Google would have let this slip through. I probably wasn't the only one that got caught out.
I am so frustrated at Google, not just for this incident, but for many reasons (like their inexplicable shutdown of my own Adsense account years ago, and their neglect of several products I'd built against or bought). When they act, they leave us with no recourse. I feel anxious being dependent on them, even for simple stuff like my email account.
They are sufficiently big that they no longer care about the little guy anymore. They are only interested in swallowing up all the World's data and cashing in on Workspace.
I think what happens is a legitimate business with a history of legit Google advertising gets compromised by malware, and then their Google adverts are flipped.
Thanks for your job!
Trust is also user specific now.
It’s not a silver bullet but it does help address some potential attacks and gives us a foundation to improve on over time.
> as-console-user command [args …]
> Run a Homebrew command as the active macOS console user.
> This is intended for MDM, Munki and Jamf workflows where brew is invoked as root but Homebrew operations should run as the logged-in console user. The nested command is always dispatched through HOMEBREW_BREW_FILE.
— https://docs.brew.sh/Manpage#as-console-user-command-args-
This isn’t very informative. Is there more documentation somewhere else that I’m missing? Google search doesn’t really find much.
I currently have a dedicated `homebrew` user that I access with `alias brew='sudo --set-home --user=homebrew --chdir /Users/homebrew -- brew' but it’s got a number of shortcomings. What will as-console-user do differently to this?
So I have a system Python (largely unused), a Homebrew python (pulled in as a dependency, I won't use it), and as many different mise/uv Pythons as I need for different projects. Similarly NodeJS and Java. I'd given up on nvm a while back, no longer use pyenv, and mise and uv work together really nicely.
That was when I realized Homebrew is much, much harder.
Your server needs to implement the git protocol. You can't just stick it on some server with a CDN in front of it, you need to run and fortify a git server.
Strange choices IMHO.
You’re maybe thinking of the creator mxcl’s viral tweet about not getting hired at Google. He did work at Apple for a while on SwiftPM.
I also am in the “applied and didn’t get hired by Google” club which let me move back to Scotland instead :)
I also applied and failed a final stage job interview at Google (and various other places over the years) but never really bothered me that much.
Ironically I think I’d probably never have started working on Homebrew if it had.
hmm... that's too bad.
Absolutely!
I am using my own custom "package" manager in ruby, but naturally it is nowhere near as sophisticated as homebrew. I am looking more towards complementing this, but these days I also lack time for more thorough testing, so I try to minimize pain points (and thus also less frequently use software written by others for the most part, unless it is a key project such as libreoffice and what not).
There are many thousands of users of Linux homebrew, mostly users of atomic distros. I am one of them. I was so happy using homebrew that I've added new formula to its repo, far2l-tty
It’s taken a long time but we’re finally at the point where we do (pretty much) only upgrade the minimal software we need to actually avoid breakage rather than the previous “better safe than sorry” conservative approach. We also now tell you by default everything we’ll upgrade before we do it (unless you say “upgrade foo” and all we are gonna do is upgrade foo).
So: we’ve maybe solved this issue and maybe not. The perfect outcomes for everyone here is pretty much impossible given the original design of Homebrew. MacPorts or Nix or Mise are likely a better fit in that case.
> Adjust how often this is run with `$HOMEBREW_AUTO_UPDATE_SECS` or disable with
> `$HOMEBREW_NO_AUTO_UPDATE=1`. Hide these hints with `$HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).