17

I wonder how programs should be installed on Mac? Via Homebrew or an official installer if there is one?

Let's say I want to install Node.js on my Mac. The official macOS installation guide offers different alternatives to do so. So first, I installed it via its official installer file. I then switched to Homebrew and installed it via brew install node.

So now it seems that I have two installations of Node on my system. When I run the command which node it outputs /usr/local/bin. So clearly the official installation is in favour here (maybe because I installed it first? I don't know). The node installation from Homebrew is in /usr/local/Cellar.

So my questions are:

  1. Should I use Homebrew or the official installer? Why? For me it seems like Homebrew has some advantages over an installer like an easier uninstalling process and a better possibility to update the installed software packages.
  2. How can I switch my system from the usage of the /usr/local/bin Node installation to the /usr/local/Cellar one?
4
  • 5
    I believe that the "official" version would have been installed in /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 – Matthew Barclay Aug 31 '20 at 13:16
  • also, do a 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 number – Matthew Barclay Aug 31 '20 at 13:21
  • Even with the Node.js installer you usually don't install to /usr/bin (in recent versions of macOS you probably can't anyway). Homebrew usually links into /usr/local/bin so you may want to check whether the file there is just a symlink into the Cellar. – nohillside Aug 31 '20 at 13:22
  • @MatthewBarclay, you can also use the command realpath $(which node) to find the actual path of the node binary – peterchaula Jun 9 at 11:10
8

There's a similar question here on Ask Different - What are pros and cons for MacPorts, Fink and Homebrew? - that does a comparison of the different package managers. It's an excellent read and I encourage you to review it.

Should I use Homebrew or the official installer? Why?

The main difference between using Homebrew and using the installer package is the build time dependencies. Homebrew (and MacPorts) does an excellent job of managing all of this. However, with the package, there's no build requirements and the software is ready to go.

Uninstalling is hardly an issue anymore. Homebrew will manage the uninstall process and handle the run time dependencies trimming them if needed. However, with free apps like AppCleaner, thoroughly removing an app is not an issue.

So, bottom line is it comes down to your workflow. If you simply need a utility download the package. If you utilize more than one and there are shared libraries that you want the ability to manage, go with Homebrew.

How can I switch my system from the usage of the /usr/local/bin Node installation to the /usr/local/Cellar one?

You change your path.

Depending on your shell (~/.bash_profile for Bash and ~/.zprofile for Zsh) you merely add the directory of new utility (see ZSH: .zprofile, .zshrc, .zlogin - What goes where? for more info). To ensure that it gets selected before the other (native) application, you put it first in the path variable. For example, the default path is (set by path_helper)

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

In your profile, simply add the line to where your binaries are. Using your example, to add your path:

PATH=/usr/local/Cellar:$PATH

Your new path will have your Cellar directory prepended to the existing one. Because it's prepended (comes before) your existing path, it will look in that directory first. See the Homebrew Documentation for full details. I personally use a combination of MacPorts and "official" installers so I use a different directory structure. YMMV.

4
  • 4
    PATH=/usr/local/Cellar:$PATH should be PATH=/usr/local/Cellar/package/version/bin:$PATH. And in fact, it should simply be PATH=/usr/local/bin:$PATH which contains the symlinks brew installs. – anki Aug 31 '20 at 14:10
  • 1
    @anki My goal here is to educate the OP on how to modify things to fit their needs, not to given an answer as to where Homebrew defaults it's path to. The end result is to determine what works best, not a Homebew HOWTO – Allan Aug 31 '20 at 14:20
  • 1
    @Allan that would be a good goal, but we'd also need to educate OP to the fact that lookups in PATH aren't recursive and binaries aren't directly in /usr/local/Cellar. So even though there's a node directory in /usr/local/Cellar in $PATH, the node command buried down in /usr/local/Cellar/node/<some-version>/bin won't be found. – muru Sep 1 '20 at 5:10
  • Why the fixation on that particular path? I literally said using your example since that was the question as written. You are over thinking this because nowhere did I say path searches were recursive. In fact, i said to “use the path where your binaries are and linked to the Homebrew docs. Again, I’m addressing the question as asked and not writing a Homebrew HOWTO – Allan Sep 1 '20 at 5:17
5

Should I use Homebrew or the official installer? Why?

I'll always prefer a package manager like brew or conda over .pkg files which don't provide uninstallers.

  • One can check what dependencies are going to be installed.
  • Easy cleanup.
  • No need to remember if something came with the standard macOS installation or installed later on.
  • No need to type in root password.

Tools not found on brew and that I build myself are built with CMAKE_INSTALL_PREFIX and installed in ~/Applications. Binaries that I download directly from somewhere are also kept in ~/Applications

Then I add the install path to PATH by ~/.bash_profile.


brew keeps the actual binaries or libraries in /usr/local/Cellar/<package>/<version>/bin and creates an alias in /usr/local/bin or /usr/local/lib or include. And puts the path /usr/local/bin in your PATH variable.

So clearly the official installation is in favour here (maybe because I installed it first? I don't know)

No it's the precedence. In PATH variable, /usr/local/bin is mentioned before /usr/bin by default. (See the install.sh file). So when a binary is found, upcoming locations are not checked.


What you downloaded from the site is a simplified

curl "https://nodejs.org/dist/latest/node-${VERSION:-$(wget -qO- https://nodejs.org/dist/latest/ | sed -nE 's|.*>node-(.*)\.pkg</a>.*|\1|p')}.pkg" \
> "$HOME/Downloads/node-latest.pkg" \
&& sudo installer -store -pkg "$HOME/Downloads/node-latest.pkg" -target "/"

I'd guess that node is installed in /usr/bin.


So to clean things up,

  • Run brew uninstall node
  • Get the xz file from https://nodejs.org/dist/latest/ and check its contents.
  • One by one, find all the folders and files like README and changelog that match the xz you downloaded, and delete them. Most probably, they can be found at /usr/bin, /usr/local/bin. What would help here is using finder and sorting by "Date Added".
  • brew install node.

How can I switch my system from the usage of the /usr/local/bin Node installation to the /usr/local/Cellar one?

After you've done the steps above, and the brew installation is correct, i.e. echo $PATH contains /usr/local/bin, you don't have to do anything extra.

2
  • How big a footprint does HomeBrew have? – benwiggy Aug 31 '20 at 14:25
  • ~ 350 MB for the git repo and some cache of downloaded binaries. Installations take the size they'd take anyway so it doesnt matter. – anki Aug 31 '20 at 16:03
2

If you're planning to install a lot of stuff, then you may find a package manager more useful; if there's only a handful of things that you need to install, which have their own installers and for which updating is easy, then installing something like HomeBrew may just add another layer of complexity.

There are also security implications to putting all your eggs in one basket. https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab

2

Regarding your first question Should I use Homebrew or the official installer? I feel the need to add a downside of using Homebrew which I didn't see here or in the other question: long term compatibility.

Take for example El Capitan, which is installed on Macs that cannot be upgraded further. While those Macs still can function fine, Homebrew (as Apple) has dropped support for this OS version. Now if you try to brew install something on El Capitan it might work, it might fail, or it might start a lengthy compilation procedure and then fail.

I found it's not worth trying out this process every time, so now on the old machine I install everything with the official installer.

6
  • 1
    Why can't you install specific versions of the formulae? See: stackoverflow.com/questions/3987683/… – Allan Aug 31 '20 at 22:18
  • @Allan This won't allow to install new versions of the respective binary – nohillside Sep 1 '20 at 6:08
  • I get that @nohillside, I would expect that the most recent compatible version to be installed by specifying it. – Allan Sep 1 '20 at 6:11
  • @Allan I'll try that, but then the hunt starts for the last version on homebrew that was compatible with El Capitan. Also, I recall something about El Capitan bottles (those are the compiled brew formula's, right?) slowly disappear from the homebrew servers. – Saaru Lindestøkke Sep 1 '20 at 7:27
  • I can’t speak to what happens on the Homebrew servers aside from the fact that I use MacPorts (mainly because it’s based off the BSD ports model; see FreshPorts). However, I’ve been able to find older versions for pretty much everything I’ve needed all the way back to Lion on PPC machines - pkg, port, and source. – Allan Sep 1 '20 at 16:43
2

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:

  1. For packages (script, documentation, etc) that aren't available on MacPorts
  2. Packages for which you wish to make coding changes & compile yourself
0

I tend more to macports/homebrew rather than official installers due to security concerns.

There have been a number of incidents where software providers/vendors have had their servers compromised and malware was injected into the downloads.

This can, quite possibly, also happen on macports/homebrew, but the difference is mainly that the people looking after those repositories are expecting constant malicious behavior and can be expected to have some expertise at stopping the bad guys. Lots of eyeballs too. If worse comes to worse, chances are somebody else will have problems from macports/homebrew before me, due to high traffic.

Whereas a company/developer who primarily writes some software package will primarily have expertise in writing their software rather than securing their download servers. Now, most of them probably do a very good job nevertheless, but you have to depend on all of them getting it right, instead of just 1-2, macports and homebrew. Once compromised, it could stay so for a while before people realize about it.

You can also quickly run some form of port outdated report to catch what needs patching.

At the end of the day, every time you install something you are taking some level of risk. @benwiggy's word of caution is totally on point here.

0

It depends I would not give one answer except do not mix homebrew and individual installs.

However if you use Homebrew you cannot use official installers for cases like node. This is because both homebrew and node want to use /usr/local which is the most common place to install third party software under unix like operating systems. The stand build software eg GNU's auto tools installs by default in there so most installers will put it in there. If you have installed third party software in that directory homebrew can get confused see questions here with brew doctor output.

Other package managers install in other directories so that they allow /usr//local for your use. Macports uses /opt by default but can use other directories. Fink uses /sw

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .