Is it safe to install both Homebrew and Macports on the same machine?

Question

I have MacPorts installed on my iMac with a fair number of ports installed.

I'm interested in trying out Homebrew, though, as I've heard many good things about it, and because I've noticed that it contains more up-to-date versions of several of the tools that I use.

But can the two coexist on the same machine, or do I need to uninstall MacPorts entirely first?

Also, if the two can be installed at the same time, will they be completely independent of each other? One of the features of Homebrew is that is doesn't reinstall new versions of things which are already included in the system (e.g. python). Does this also extend to it not installing versions of things which are already maintained by MacPorts?

What happens if I then subsequently uninstall MacPorts?

Answer 1

They will not coexist well together. The Apple gcc looks in /usr/local for some things. This means that a macports compile could find something the porter did not expect. See macports mail lists and bugs for examples of things found in /usr/local.

Answer 2

I gave another answer on a similar question:

Homebrew will cause problems when building software from source if it is installed in /usr/local. This is the default, which is a bad choice as this path is in the default search path of compilers and other tools. Therefore builds from other packaging software might pick up the wrong dependency, using Homebrew's version instead of their own.

Years ago, in the very beginning of the project, even MacPorts was using /usr/local. But it turned out not to cooperate with other tools as is documented in their FAQ. Unfortunately Homebrew developers didn't want to hear about prior experiences and ignored such facts...

In general, it is usually better to stick to one tool only to avoid all problems. MacPorts is doing their best to patch out any harcoded paths, e.g. to /sw which is used by Fink. So usually it will work, but having anything installed in /usr/local will definitely cause problems for it.

[…]

Answer 3

I used to think that worries about what the Gnu build tools will make of /usr/local were verging on paranoid. The build tools expect there to be lots of things there: in the good old days before package managers (I joke), we compiled whatever to /usr/local. But while Autoconf usually does figure out issues, the sheer build complexity of many open-source projects does cause problems and these problems can be hard to back out of when you get into difficulty.

But the risk of trouble with Autoconf finding something it shouldn't under /usr/local needs to be balanced about the maintenance nuisance having two, three, or four different different copies of Perl, Tcl, and Ruby, each with different coverage of their different package libraries. Unpleasant.

Since my experience with MacPorts and Fink has typically been exasperation caused by exactly this, and at some point switching to compiling the old-fashioned way to /usr/local, I was pleased to see that Homebrew didn't mess about with that. I tried configuring MacPorts to install to /usr/local, but MacPorts goes out of its way to make that difficult. I understand that the motivation is to make life easier for themselves when dealing with cries for help on their mailing list and bug tracker: please be aware, though, that while we should respect the effort of volunteer packagers and treat their time as precious, their debugging convenience is not the only sort of simplicity that affects you, as a user.

Homebrew, in this respect at least, does things the way they used to be done, and MacPorts tries not to interfere. If you are willing to document which packages you need with Homebrew, and wipe /usr/local clean and reinstall in case of difficulties, then you can always back out in the case things go badly wrong. And once you realise that problems in /usr/local do not generally carry the risk of permanent damage to your machines, you may feel freer to take risks.

I'll just note how much worse packaging is on OSX than FreeBSD: Apple does not really seem to care about the usability of its BSD subsytem, because this is a problem they could help with.

Answer 4

According to the MacPorts FAQ:

Note that starting with 2.3.0, MacPorts can automatically hide /usr/local (and all other files a port does not depend on) from ports' build systems. This feature is called trace mode and is activated by providing the -t flag to port, e.g.

sudo port -t install <portname>

This is relevant because according to the Homebrew Installation Page:

One of the reasons Homebrew just works relative to the competition is because we recommend installing to /usr/local. Pick another prefix at your peril!

Therefore, and with little personal experience, I theorize that always using the -t flag for MacPort installs should prevent most problems of having MacPorts and Homebrew coexist on the same system. To address your last question: I don't see any reason why uninstalling MacPorts would cause any problems.

Answer 5

While installing homebrew on a computer where I've been using ports for years, here is what I can read:

Warning: You have MacPorts or Fink installed:
  /opt/local/bin/port

This can cause trouble. You don't have to uninstall them, but you may want to
temporarily move them out of the way, e.g.

  sudo mv /opt/local ~/macports

Be careful!

Answer 6

webappzero's sudo port -t ... solution should help. To be honest, I run with Fink, MacPorts and Homebrew all at once, with deference to MacPorts (for now anyway), and only using either of the other two to install things I can't get from MacPorts. I've run into very few difficulties this way, even before learning the port -t trick. If you're trying to use multiple package managers to maintain complex development and server environments, though, you're probably in a for a world of discomfort at least. Pick one, and avoid the others but for something you desperately need from them, and put the main one earlier in the path.

If what I'm hearing is true about Apple going to forbid things to install into /usr/ other than Apple's own (or maybe they're already doing that in El Crapitan, which I'm avoiding "up"grading to until after more problems with it are resolved), I suppose that will mitigate the issue after Homebrew defaults to using something else – whether we agree with Apple's heavy-handed approach or not.

In the end, I like the idea of confining Apple's own ports to its own tree, I just wish it wasn't /usr/. I'd rather they'd used /System/bin/, etc., etc., to isolate their own stuff, so I could bypass it with up-to-date, community-maintained software more easily.