What is the difference/usage of homebrew, macports or other package installation tools?

Question

I've just recently switched to a Mac from Ubuntu. I was disappointed that mac doesn't have the convenient sudo apt-get in Ubuntu. I've heard that I should use homebrew but I'm not exactly sure what homebrew or macports does?

much related: http://apple.stackexchange.com/questions/32724/what-are-pros-and-cons-for-macports-fink-and-homebrew — cregox, Jun 15 '14 at 22:02
A few years ago the homebrew front door had a statement that went something like this "homebrew is better because it's written in Ruby". I have nothing against Ruby mind you, not at all. I like oop and ruby is a fine oop language. What I have a problem with is any software developer that thinks one language is better than all others. For that reason alone I have no interest in homebrew. Also, macports has been working fine for me for many years. — Mike Makuch, Apr 12 '15 at 03:30

score 158 · Answer 1 · edited Feb 16 '15 at 10:32

158

MacPorts is the way to go.

Like @user475443 pointed, MacPorts has many many more packages. With brew you'll find yourself trapped soon because the formula you need doesn't exist.
MacPorts is a native application: C + TCL. You don't need Ruby at all. To install Ruby on Mac OS X you might need MacPorts, so just go with MacPorts and you'll be happy.
MacPorts is really stable, in 8 years I never had a problem with it, and my entire Unix ecosystem relay on it.
If you are a PHP developer you can install the last version of Apache (Mac OS X uses 2.2), PHP and all the extensions you need, then upgrade all with one command. Forget to do the same with Homebrew.

MacPorts support groups.

foo@macpro:~/ port select --summary

Name        Selected      Options
====        ========      =======
db          none          db46 none
gcc         none          gcc42 llvm-gcc42 mp-gcc48 none
llvm        none          mp-llvm-3.3 none
mysql       mysql56       mysql56 none
php         php55         php55 php56 none
postgresql  postgresql94  postgresql93 postgresql94 none
python      none          python24 python25-apple python26-apple python27 python27-apple none

If you have both PHP55 and PHP56 installed (with many different extensions), you can swap between them with just one command. All the relative extensions are part of the group and they will be activated within the chosen group: php55 or php56. I'm not sure Homebrew has this feature.

Rubists like to rewrite everything in Ruby, because the only thing they are at ease is Ruby itself.

edited Feb 16 '15 at 10:32

AdrieanKhisbe

3,899
8
37
45

answered Jul 22 '14 at 17:37

noun

3,635
2
25
27

30

Rubists like to rewrite -- hehe, have a look at NodeJS guys implementing binary protocols for MySQL in JS! :) – kolypto Sep 05 '14 at 10:48
40

You do not need MacPorts to install Ruby — Ruby is included with OS X, and brew uses the system Ruby. – Michael Ekstrand Dec 08 '14 at 23:25
6

@Michael Ekstrand OS X doesn't include the last version of Ruby. – noun Dec 08 '14 at 23:58
94

Can't upvote this. It's too snarky, and the snarkiness undermines the information. – OldPeculier Feb 12 '15 at 21:31
39

Upvoting to counter the omitted "anti-snarky" upvotes. Any information received from a human being will always have a natural bias ("snarkiness" in this case). I appreciate this user's perspective, perhaps specifically *because* the answer doesn't read like a wikipedia entry. – rinogo Mar 23 '15 at 20:24
1

@noun Homebrew works with OSX's version of Ruby, and can install the latest version of Ruby. – Shane Daniel Mar 27 '15 at 21:54
1

@noun just wanted to point out that you're not going to find the "latest" version of many programming languages on many operating systems at all, considering the operating systems ship with a "system" binary in /usr/bin and you're expected you use a package management system (brew, apt, yum, etc) to install the "last" version. I'm downvoting for that comment alone. You should be using `/usr/local/bin` or `~/bin` and editing your `$PATH` to find the right version anyway. Personally I've found Brew and Brew-Cask are perfect for me. I `brew cask`'d macports, but have never needed to use it. – Charles D Pantoga Feb 27 '16 at 04:17
I couldn't get npm to work with macports. Node worked though. That's why i switched to Homebrew. Had no problems with other packages on MacPorts. – Jo Smo Oct 24 '16 at 14:56
2

MacPorts may have more packages, but the problem is that the packages are very out of date, and thus practically useless. As just 1 example, consider Tomcat, where MacPorts is still using version 6 (2 major versions behind), and there's a ticket over *6 years old* asking for an upgrade: https://trac.macports.org/ticket/28938. HomeBrew has a much more active community. MacPorts may have more packages, but only because it's been around longer. HomeBrew is the future, and it's just a matter of time before it hits critical mass. – user64141 Nov 12 '16 at 18:12
@user64141 the future is containerization. People don't need to install anymore the Linux ports, because the dev environment is provided by a set of containers. I have written this answer almost 3 years ago, and I'm more convinced than ever that tools like MacPorts and Homebrew are losing their importance. Btw, Homebrew will be dead soon because Ruby itself is a zombie. – noun Dec 27 '17 at 19:54
@noun Containerization is great for everything that runs as a service. Like the tomcat mentioned. But for shell utilities package managers are still important. – Gellweiler Mar 06 '18 at 16:41
@Gellweiler that's true, but in many cases you are going to use these utilities inside the containers. There are exceptions, of course, and we will still need ports, but as you said, probably just for the shell utilities. – noun Mar 06 '18 at 17:08
One more point, Homebrew remove the version you use which are deprecated regardless of your pain to fix your working applications to support newly `upgraded` version of softwares. This is crazy and enough to stop using homebrew ANYMORE – tom10271 Feb 17 '21 at 01:57
MacPorts also provides a better support of universal packaging – Saitama Mar 07 '23 at 12:28

score 111 · Answer 2 · edited Mar 05 '18 at 22:03

Homebrew and macports both solve the same problem - that is the installation of common libraries and utilities that are not bundled with osx.

Typically these are development related libraries and the most common use of these tools is for developers working on osx.

They both need the xcode command line tools installed (which you can download separately from https://developer.apple.com/), and for some specific packages you will need the entire xcode IDE installed.

xcode can be installed from the mac app store, its a free download but it takes a while since its around 5GB (if I remember correctly).

macports is an osx version of the port utility from BSD (as osx is derived from BSD, this was a natural choice). For anyone familiar with any of the BSD distributions, macports will feel right at home.

One major difference between homebrew and macports; and the reason I prefer homebrew is that it will not overwrite things that should be installed "natively" in osx. This means that if there is a native package available, homebrew will notify you instead of overwriting it and causing problems further down the line. It also installs libraries in the user space (thus, you don't need to use "sudo" to install things). This helps when getting rid of libraries as well since everything is in a path accessible to you.

homebrew also enjoys a more active user community and its packages (called formulas) are updated quite often.

macports does not overwrite native OSX packages - it supplies its own version - This is the main reason I prefer macports over home-brew, you need to be certain of what you are using and Apple's change at different times to the ports and have been know to be years behind updates in some projects

Can you give a reference showing that macports overwrites native OS X packages? As far as I can tell, all macports installation happens in /opt/local

Perhaps I should clarify - I did not say anywhere in my answer that macports overwrites OSX native packages. They both install items separately.

Homebrew will warn you when you should install things "natively" (using the library/tool's preferred installer) for better compatibility. This is what I meant. It will also use as many of the local libraries that are available in OS X. From the wiki:

We really don’t like dupes in Homebrew/homebrew

However, we do like dupes in the tap!

Stuff that comes with OS X or is a library that is provided by RubyGems, CPAN or PyPi should not be duped. There are good reasons for this:

Duplicate libraries regularly break builds

Subtle bugs emerge with duplicate libraries, and to a lesser extent, duplicate tools

We want you to try harder to make your formula work with what OS X comes with

You can optionally overwrite the macosx supplied versions of utilities with homebrew.

macports does not overwrite native OSX packages - it supplies its own version - This is the main rason I prefer macports over home-brew, you need to be certain of what you are using and Apple's change at different times to the ports and have been know to be ye3srs behind updates in some projects — mmmmmm, Feb 26 '14 at 11:43
Can you give a reference showing that macports overwrites native OS X packages? As far as I can tell, all macports installation happens in `/opt/local` — , May 11 '14 at 01:45
You did at the least imply very strongly that MacPorts overwrites native OS X packages. Instead of "clarifying" while still pretending you didn't say wrote what you wrote, you should probably edit the sentence in question. — Relaxed, Mar 26 '15 at 12:10
This sentence, "One major difference between homebrew and macports; and the reason I prefer homebrew is that it will not overwrite things that should be installed "natively" in osx." should be changed to "One major difference between homebrew and macports; and the reason I prefer homebrew is that homebrew won't automatically install parallel copies of tools and libraries that are already provided by Apple." — bgupta, Oct 04 '15 at 11:23
MacPorts doesn't overwrite native apps, it "Confines ported software to a private “sandbox” that keeps it from intermingling with your operating system and its vendor-supplied software to prevent them from becoming corrupted." - MacPorts Guide, Chapter 1 — jla, Jan 12 '16 at 18:30

score 23 · Answer 3 · answered Jun 13 '14 at 05:34

23

Currently, Macports has many more packages (~18.6 K) than there are Homebrew formulae (~3.1K), owing to its maturity. Homebrew is slowly catching up though.

Macport packages tend to be maintained by a single person.

Macports can keep multiple versions of packages around, and you can enable or disable them to test things out. Sometimes this list can get corrupted and you have to manually edit it to get things back in order, although this is not too hard.

Both package managers will ask to be regularly updated. This can take some time.

Note: you can have both package managers on your system! It is not one or the other. Brew might complain but Macports won't.

Also, if you are dealing with python or ruby packages, use a virtual environment wherever possible.

answered Jun 13 '14 at 05:34

user475443

511
5
8

2

{{{ Sometimes this list can get corrupted and you have to manually edit it to get things back in order, although this is not too hard. }}} I have never seen this happen, though that's not to say that it's not possible. What were the circumstances? Did you file a bug (http://trac.macports.org)? – LSpice Jun 29 '14 at 01:29
{{{ Both package managers will ask to be regularly updated. This can take some time. }}} This seems like a strange statement. In several years of use, I only remember upgrading MacPorts itself a few times, and the update is rather quick. Do you mean that the ports themselves have to be updated frequently? Well, they *can* be, but that's a good thing, not a drawback, I think! Also, it's probably worth noting that MacPorts won't *ask* to do anything—that is, there's no nagging; you have to ask *it* about out-of-date packages. – LSpice Jun 29 '14 at 01:32

score 18 · Answer 4 · answered Jan 27 '14 at 07:42

18

By default, Homebrew installs packages to your /usr/local. Macport commands require sudo to install and upgrade (similar to apt-get in Ubuntu).

For more detail:

This site suggests using Hombrew: http://deephill.com/macports-vs-homebrew/

whereas this site lists the advantages of using Macports: http://arstechnica.com/civis/viewtopic.php?f=19&t=1207907

I also switched from Ubuntu recently, and I enjoy using homebrew (it's simple and easy to use!), but if you feel attached to using sudo, Macports might be the better way to go!

answered Jan 27 '14 at 07:42

debstep

189
2

5

Are you saying that homebrew installs things into `/usr/local` without requiring sudo? – May 11 '14 at 01:46
1

@NgocPham Do you have a reference for that? – May 17 '14 at 17:19
1

@Articuno you can reference the Homebrew FAQ page here: https://github.com/Homebrew/homebrew/wiki/FAQ#why-does-homebrew-insist-i-install-to-usrlocal-with-such-vehemence – Keith May 17 '14 at 18:42
17

@Keith That site is incorrect. Or at least, it is leaving out a major premise. It says "Apple has left this directory for us. Which means there is no /usr/local directory by default, so there is no need to worry about messing up existing tools." Apple has not left `/usr/local` for Homebrew. Apple has left `/usr/local` for "executables, libraries, etc. not included by the basic operating system". That means it's possible that tools installed prior to using Homebrew may have created `/usr/local` such that it can't be modified without `sudo`. They don't discuss that at the wiki. – May 17 '14 at 18:47
@NgocPham and @Keith If `/usr/local` has permissions `drwxr-xr-x 6 root wheel`, how does Homebrew install stuff there without `sudo`? – May 17 '14 at 18:50
See [this answer](http://apple.stackexchange.com/questions/1393/are-my-permissions-for-usr-local-correct): "*keeping /usr/local owned by root means that only processes that run as root/sudo can write to this area*" – May 17 '14 at 18:54
Of course if `/usr/local` has its ownership changed, then sudo may or may not be required. Homebrew's statement is that `/usr/local` defaults to a set of permissions which do not require root access to modify. – Keith May 17 '14 at 20:17
If the entire file system is changed so that it is owned by root and only has permissions for the owner, then no package manager could create or modify any file at all without sudo/root access. – Keith May 17 '14 at 20:18
@Keith However, `/usr/local` *doesn't* default to a set of permissions which do not require root access to modify. On a fresh installation of OS X, you require root access to modify `/usr/local`. – May 18 '14 at 06:28
@Articuno I don't get your point. What are you trying to defend here? The problem with `homebrew` and its statement on the use of `/usr/local`? The fact that you are right, that this directory might have been created before `homebrew` by another installation, and without `sudo`, `homebrew` cannot simply install stuff into that directory. But it doesn't make any sense compared to the convenience of not having to type sudo (and password) every time we install an external library. It might have down points, but it's what we, the `homebrew` users, are happily live with. – Ngoc Pham May 18 '14 at 19:55
2

@NgocPham My point is that I don't believe that Homebrew can use `/usr/local` without root permissions. The default permissions for `/usr` on a fresh OS X install are root owner, with no write permissions for anyone else. In order to even *create* `/usr/local`, Homebrew would need root access. (I'm not trying to defend anything) – May 19 '14 at 01:07
5

@Articuno I think I got you now. It's just the statement that `homebrew` can install stuff without `sudo` because when it set itself up, it **used** `sudo` to make the permission on the directory looser so it will be able to do anything inside `/usr/local` without triggering the password. Does it mean the "install without password" part is wrong? I don't think so! It's still true that `homebrew` **will** be able to get stuff without the password. – Ngoc Pham May 20 '14 at 00:30
@NgocPham Yeah, that's exactly it. Homebrew moves the sudo to the initial installation of Homebrew itself, in order to avoid sudo with every Homebrew command. – May 20 '14 at 00:34
1

MacPorts *by default* requires sudo to install itself and ports, but it is certainly possible to (build it from source and) install it and packages without root privileges. I have run it this way for years with no problems (except that installing `dbus` appears to require root privileges—but maybe there's some way around even this). – LSpice Jun 28 '14 at 20:48
2

I seriously believe altering the permission of a core directory is a very bad design decision. Don't get why homebrew just doesn't use /usr/local/homebrew or /opt/homebrew. I guess because /usr/local/bin is in $PATH by default. Also in general on *nix systems, if you don't want to do stuff with root permissions, just do it in user space. Homebrew can be configured of course to use sane directories. I just feel Macports is the more UNIX way of doing things, coming from BSD and all. – Gellweiler Mar 06 '18 at 16:26

What is the difference/usage of homebrew, macports or other package installation tools?

4 Answers4

Linked