I wonder how programs should be installed on Mac? Via Homebrew or an official installer if there is one?
Other answers here have addressed various specifics. I'll restrict my answer to this question, make some recommendations, and briefly explain them.
Role of a package manager in macOS
I think most users of the various Linux and BSD distributions have come to appreciate the importance of a good package manager. I use mostly Debian-based distros, and regard the package manager (aptitude
) to be as essential as the kernel itself. By that I mean if the package manager didn't exist, or if it was unreliable and prone to error, then I would not be a Linux user.
Apple has chosen not to provide a package manager per se. Apple provides a selection of open-source tools - they are bundled with the macOS distribution, and updated at Apple's discretion. But there is a huge world of open-source software available; much of it is excellent quality and offers substantial advantages over closed-source software.
For anything more than 2-3 packages, I feel most users are best served by using a package manager. Some packages support stand-alone installation very well on macOS. Some even support updates, and a few support removal also. But these will inevitably be different, package-unique procedures, and maintenance becomes a time-consuming chore.
Comparison of package managers in wide use on macOS
I believe that there are three package managers in wide use on macOS:
Some will disagree with my designation of git
as a package manager. I won't argue that in a strict sense git
is version control software, but I feel that when git
is coupled with huge collections of free and open open source repositories, the differences seem to fade into obscure jargon.
I tried Homebrew several years ago, and most of my opinions were formed by that experience. Simply put, despite the fact that I had some experience with package managers when I first tried Homebrew, I found it to be awkward and unreliable. Package locations, "on-again, off-again usage of sudo
", jargon that referred to beer-making: "brew = make ?", what's a "cask"?, and use of Ruby (which is great if you're a user, but I'm not) all contributed to its lack of appeal. But some love it, and for those people, I'll only say, "Party on, Garth"!
Shortly afterward, I decide to give MacPorts a go, and I've been using it ever since. I think this is mostly due to the fact that it strikes me as rational, straightforward and easy-to-use. It offers a lot of depth for unusual situations that come up from time-to-time, but becoming productive with it requires only a few minutes and a handful of commands; proficiency can be achieved in a few hours. In summary, MacPorts is my unreserved recommendation for a pure package manager.
A few words about git
, and why I think it's a useful "package manager". As a version control tool, git
is a complex piece of software that requires much effort to master. You can get a sense for this by perusing the many man
pages for git
, and its various subsidiaries. However, using it to "install" and update packages hosted on a git
repository (GitHub for example) requires only a few commands. I feel it's primarily useful in two situations:
- For packages (script, documentation, etc) that aren't available on MacPorts
- Packages for which you wish to make coding changes & compile yourself
/usr/bin/
, as only Apple-approved programs are allowed to be installed there. If I were you, I'd open up Finder, and take a look at the/usr/local/bin/
folder. You might find that/usr/local/bin/node
is a symlink to/usr/local/Cellar/node
node --version
and a/usr/local/Cellar/node/node --version
(adjusting the second version to fit what's on your computer), and comparing the two version numbers. You usually will want the version with the higher version numberrealpath $(which node)
to find the actual path of the node binary