somewhere under the home directory as opposed to the default global New terminal session every time right before running brew, on top ofīeing a performance nightmare! The bad: separate Homebrew installationsĪnother approach that’s not as widespreadĪs the first one is to maintain a separate brew installation per user,Į.g. Similar to prevent this, which will still fall apart if you don’t open a You see setups as crazy as running the chmod command in ~/.zshrc or Running the chmod hack again, but that’s flaky and won’t event prevent This means that if you instal packages from different users, brew update will very quickly fail to run on any of those users because Permission for the newly created files won’t have group write access. Use brew, more and more parts of the state will not be writable by theįor example if after running the earlier hack, you run brew install some-package as user foo, then you won’t be able to brew uninstall some-package or brew update some-package as user bar, because the That brew uses doesn’t add group write access, meaning that as you The illusion that you allowed brew to be used by multiple users. That is shared by all the users you want to call brew from, you get A given Homebrew installation is only meant to be used by aīy giving write access to a given group (in the above example, admin), The problem is that Homebrew is not designed to be used by multiple Same, and it appears to work at first, until it doesn’t. Some use a custom group instead of admin. Some variants use brew -prefix instead of hardcoding /usr/local, To try to do this, a simple search for this yields a fuckton of results!Īnd they all mostly share the same “tip” which is some variant of: chgrp -R admin /usr/local/* The evil: shared group writable permissions Out of the box, if you install it from one user, it’ll just fail to doĪnything when run from another user because of permission issues. The tool I install macOS packages with, and which I happen to use both The main issue I ran doing that was about running Homebrew, Sharing a homebrew is nice 🍺, but brew not so much User for work, this way everything would be neatly contained. Professional environment was a bad idea, I decided to create a dedicated So after realizing that merging my personal projects with my

Personal credentials to the mix sounds like a recipe for disaster. Staging and production environments in the same session that adding my Shell history and making me press the up arrow even more than I alreadyĭo, it quickly feels like poor hygiene to keep everything under the sameĪnd while some of those tools allow to authenticate with multipleĪccounts and offer ways to configure them individually and switchīetween contexts, I’ve seen enough mistakes happen by juggling between Same environment, and work-specific commands popping in my personal Various unrelated developer tokens and credentials cohabiting in the Whether it’s my personal Google Cloud context leaking in my workĮnvironment, work SSH keys being available in my personal projects, If I want to work while travelling without having to bring two laptopsīut setting up a work environment on my personal computer actuallyīrings a number of concerns, mainly about: Where I’ve got the freedom to use my own rig, which is especially nice I’ve recently started working at a new company,

Need sudo access on macos homebrew