Today, I want to share my recent journey into the world of Homebrew. I’m an IT contractor in my day job, and often it’s the case that I’m expected to use my own machine for work.
I’m a lazy developer, and I often end up using my personal machine for work as well. This can lead to a bit of a messy development environment, and it can also be a bit of a security risk. The upside to allowing the use of a developers own machine is that it can lead to a more productive and efficient developer experience. I spend a lot of my own time tinkering with settings and configurations, and I’ve found that this can lead to a more conducive developer experience, it certainly makes me more productive, and from my own experience of using enterprise machines they tend to provide more obstacles than necessary when delivering valuable work. So, knowing it can be a bit of a bug bear to have to switch between my work and personal environments, I’ve been looking for ways to make this process easier.
How I’m Managing My Dev Tools
Most of my settings are handled via version control both in VS Code and in my dot files. However, I’ve found that there are a few tools that I use that are not easily managed in this way. For example, I use Alfred for productivity, and I use Homebrew to manage my development tools.
I boiled down my main dev tools to be:
- Alfred
- VS Code
- iTerm2 (and zsh/scripts/dotfiles)
- Homebrew
For Alfred, I tend to use Dropbox to sync my settings, I tried iCloud but found it to be a bit flakey. My iTerm/dotfiles bits are synced via Git. My VS Code settings aren handled via Git. My iTerm2 settings are synced via Git.
The only thing left to solve really, is Homebrew.
The Problem with Single User Homebrew
Homebrew is a fantastic package manager for macOS, but it can be a bit finicky when you’re using a “root” install. If you’ve ever ran into “issues” with Homebrew (anyone who’s ran brew doctor enough will acknowledge this), you’ll know that it can be a bit of a pain to manage. The reason for this is because Homebrew as a tool is deeply linked to the user that installed it, and it’s not really designed to be used by multiple users. If you look at the default install you will see it installed a lot of linked binaries and such into /usr/local/bin. This is fine if you’re the only user on your machine, but if you’re sharing your machine with other users, it can lead to a lot of unnecessary duplication and potential version conflicts. The way Homebrew suggests getting round this is to have a separate Homebrew installation per user, (its officially “unsupported” to have multiple users, read: https://docs.brew.sh/Installation).
The Solution: Multi-User Homebrew
So, what’s the solution? Enter multi-user Homebrew. The idea is to create a new group (let’s call it “brew”), and change the group ownership of the Homebrew directories to this group. This allows all users in the “brew” group to manage Homebrew without needing to use sudo.
I followed a fantastic guide on Medium by Leif Hanack, which you can find here. However, I ran into a few hiccups along the way, so I thought I’d share my additional troubleshooting steps with you.
Troubleshooting Multi-User Homebrew
After following the guide, I ran brew doctor and was greeted with a list of directories that were not writable by my user. This suggested that the group permissions were not set up correctly.
To fix this, I verified that my user was in the “brew” group by running groups david.yates.ext. Then, I set group write permissions for the directories with sudo chmod -R g+w $(brew --prefix)/*.
I also encountered an issue with Homebrew’s git origin remote missing. To resolve this, I added the remote by running git -C "/usr/local/Homebrew" remote add origin <https://github.com/Homebrew/brew>.
Lastly, I added Homebrew’s “sbin” to my PATH by running echo 'export PATH="/usr/local/sbin:$PATH"' >> ~/.zshrc and sourced my .zshrc file (source ~/.zshrc)to apply the changes.
The Benefits of Multi-User Homebrew
So, why go through all this trouble? For me, it’s about creating a more conducive developer experience, and allowing a clear seperation of concerns between my personal, and work projects. The trouble I often run into though, as I’m sure other dev’s might attest to - is that a lot of my day job work bleeds over into my personal projects as I often go down rabbit holes solving something for work only for it to kick off a mini project of my own. I’m hoping that by having a clear seperation of concerns between my personal and work projects, I can avoid this happening as much. There’ll likely be an update here in a month or so with me saying how wrong I was, but we’ll see.
Until then, happy brewing! 🍻