There's no requirement that Homebrew be in /usr/local. Some individual (poorly-written) packages may assume that, but I've been running Homebrew in $HOME/.brew for multiple years on multiple machines with no issues at all.
That's actually fucking brilliant, and aligns much better with what homebrew is. I'm setting up my new macbook from work tomorrow and this is absolutely the way I'm going to do it, and how I'll suggest any of my colleagues do as well.
It's also very difficult to roll back to a previous version of a package unless the maintainers specifically opt in to tagging them. Homebrew also updates itself when you install something now, so say if you install python, it might update readline, so your postgres client will break.
It's not the worst approximation of ports, but it doesn't share the quality and care that goes into package maintenance and dependency management.
Really? If you're going to do that, it seems like you might as well just merge all those users into a single account anyway, considering how trivial it would be for any one of them to execute arbitrary code as any other.
I moved away from homebrew, to compiling my own software on macOS which I just put in ~/build. I don't use sudo make install since I own the ~/build folder.
This is only about /usr/local itself, not the directories under it, the one with executables - that's still owned by you, not root. Some difference in ease of initial installation, zero difference in terms of (in)security.
This means:
1) It is a security hole; any application can now modify system-wide applications at any time.
2) You can't have multiple users able to use homebrew.
I was expecting homebrew to be something similar to apt/yum/etc, but this makes it pretty fundamentally different.
How does Macports handle this? Does $USER still need write access to /opt?