With brew as the de-facto package manager for macOS this is a great move. Having Python and Ruby bundled with macOS is confusing when trying to install "regular" versions of the software through brew or other methods. Because the default installation can't updated without updating the OS, the system versions are not useful for most developers.
Besides your tone and language being unwelcome here... you're just factually wrong. Comparing in Google Trends, it's very clear brew is the "de facto" package manager, and has been for years:
"DarwinPorts" was originally released in 2002. You can see it trending and then the name change which occurred in 2006. It's been on a downward trend ever since.
Even thought Homebrew was released in 2009, it trends relatively constant for the entire dataset. In fact, from 2009 onward, you see a downward trend and then a slight upward trend. So, I'd say, Google is having trouble differentiating "Homebrew" as a drink and Homebrew the package manager.
Now, my personal opinion on the matter:
I used both Fink and MacPorts extensively since around ~2002. I eventually moved to MacPorts because it had better support for Latex at the time.
MacPorts is solid and follows UNIX philosophy in its design. I've been using it for almost 15 years and in that time I've had almost zero issues with either available packages or installation bugs. It's very reliable.
Extend the time window and it also shows that homebrew was more popular than macports in 2004. Despite being released in 2009. (The word "homebrew" refers to more than one thing. Like the thing that the mac package manager was named after.)
Homebrew is the de-facto package manager on macOS because it is so widely used. It might not be the one started by Apple engineers, but it is certainly the more popular of the two.
Those don't seem to be opposing things - you expect your package distribution tool to be effectively curl and tarballs, the other person expects more complex behavior options and dislikes the absence of them.
Of course you are technicly right. Homebrew is a train wreck and should not be used. But people are using Windows also, they don't use the proper tools, like ports. Unfortunately it is the defacto packager.
But still, people should not put out Homebrew installation recipes, and prefer macports instead. At least you can seperate the newbies from the experienced immidiately. If it's a Homebrew package only, avoid.
* installs into /usr/local/bin, which is now a protected path with SIP. Why do you think Apple itself protected themselves from Homebrew? So what do Homebrew users do now? Disable SIP. Sigh
* installs with users permissions, not a seperate user. /usr/local/bin is now open for every pwner. The very first path, not just ~/bin.
Never trust a newbie package manager which takes over your whole system and installs into the very first path. Even macports can override the pre-installed coreutils without messing with /usr/local/bin.
Besides the security nightmares:
* is a unicorn, esp. for darwin only. macports uses the de-facto standard ports framework instead, just with tcl, not the shell.
apt or rpm are also not the standard. ports was much earlier and is used on much more platforms than those unicorns. You won't get any brew recipes from other and better managed packages. Those with a bit more experience.
/usr/local/bin is not under SIP, /usr/local is. Homebrew now changes the permissions and ownership of the directories inside of this to get around this (which is functionally the same thing, but I figured that I'd point this out to you before someone else did since your points are otherwise valid).
It's called a personal computer for a reason. Laptop sharing is not a really a thing for professionals (or at least not that common). So, complete non issue for the vast majority of the target audience (i.e. developers and techies). Actually, not requiring root permissions is a feature and not a bug as it reduces the scope of what these tools can do at the OS level, which is a good thing for software you blindly install after downloading.
Not requiring root to install software to system directories is a security bug, not a feature. In a practical sense Homebrew elevates you to root and in the process messes up the permissions of a /usr/local, which, being on $PATH, opens users up to vulnerabilities.
Nonsense. You are using users in plural. Macs are not typically used as multi user machines. Certainly not by developers. And when they are, so what? Technically, the permissions are only changed for the user that installs homebrew, which requires root access to change the permission, and not for the other users. If that's a problem for you, configure it to install stuff elsewhere.
Also, /usr/local is completely empty on a fresh OSX installation and the whole point of homebrew is to have the stuff you install with it on the path. That's the whole point; you put stuff there that isn't part of the OS because you need it. There's nothing to mess up other than the stuff that you put there. If you don't want stuff there, don't put it there. The only vulnerability is the single user of the laptop being an idiot. At least they can be idiots without defaulting to root privileges, which probably is an improvement.
Because I am talking about people who use Macs in general?
> Macs are not typically used as multi user machines. Certainly not by developers.
There are developers who share Macs: not everyone can afford to have a computer to themself. But that's still beside the point: regardless of the number of humans using the computer, Macs still have multiple permission levels, and there is always a "root" with more permissions than you.
> configure it to install stuff elsewhere
Yeah, this tends to break if you actually try this. Homebrew explicitly tells you that this is not well supported.
> Also, /usr/local is completely empty on a fresh OSX installation and the whole point of homebrew is to have the stuff you install with it on the path.
Yes, but there are better, and more secure ways to do this. What you should be doing is require sudo to install to a directory that is global and automatically on $PATH, or install locally to ~/bin (for example) and then put that on your $PATH. The way Homebrew does it, where it changes the permissions of /usr/local's folders, is bad because it opens the door to attacks when system software running as root picks up binaries from $PATH (which you have now changed ownership and permissions of to be writable by your user) making any code execution bug instantly become a privilege escalation attack. This isn't the first time I've had this discussion, so I have more detailed explanation which links to an actual example of this being exploited in practice: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
> The only vulnerability is the single user of the laptop being an idiot.
Aside from the fact that the security hole exists regardless of me doing something stupid, I'd like my software to work as well as possible in the face of me being an idiot ;)
Basically it means if someone has user access on a Mac with Homebrew (with default settings), they also have root. So a remote hole in, say, Safari, means your entire system is compromised.
They don't quite have root per se, but they have a functional elevation of privileges if some some other software has a bug in it with regards to pulling binaries from $PATH, which is quite common.
