Once installed, you control Homebrew using the brew command. You can find packages using brew search, install them using brew install and remove them using brew uninstall.
Homebrew installs packages to their own directory and then symlinks their files into /usr/local. Homebrew won’t install files outside its prefix, and you can place a Homebrew installation wherever you like.
One of the things to like about Homebrew is that it refuses to run things under sudo most of the time. This is a great policy, but it causes issues when you want to create symlinks or install in places that SIP has changed permissions on. (Alternatively, you could install Homebrew somewhere other than /usr/local, but that might break various packages that depend on having stuff in and relative to /usr/local/.)
Super annoying for upgrades when OS X updates or when some formulas do. It's a pretty janky system (perhaps the formula's problems more than homebrew itself), despite being super convenient. There are many occasions where you simply don't want to upgrade things out of fear of wasting hours fixing things.
One of the things to like about Homebrew is that it refuses to run things under sudo most of the time. This is a great policy, but it causes issues when you want to create symlinks or install in places that SIP has changed permissions on.
You can get warnings about non-homebrew files in this directory. In general there's a risk as it isn't well-isolated.
According to this article, installing in the directory poses a security risk.
Once xcode is installed you can install Homebrew, including new(er)/different versions of most of the build stuff that xcode-select installed, like a newer gcc, newer git, etc.
While this is a pro for some people, for others it's a con, especially in terms of security. If your users are non-administrators then they will not be able to run the full homebrew command because most programs prompt for sudo creds to add the application to the application folder which non-admin users cannot do.
Homebrew’s recipes try very hard to use the existing tools and libraries in OS/X, so they tend to build much faster and require fewer dependent libraries.
Macports seems to be able to get into a bad state where new packages are unable to be installed, or installed software was unable to be updated. This simply hasn't happened with Homebrew. In addition to not having to deal with corruption problems, Homebrew installs packages in userland. Not requiring root to install software is a big win.
Macports seems to be able to get into a bad state where new packages are unable to be installed, or installed software was unable to be updated. This simply hasn't happened with Homebrew. In addition to not having to deal with corruption problems, Homebrew installs packages in userland. Not requiring root to install software is a big win.
While you may be using a Mac now, it's best to be able to use your package manager on Linux if needed. And Linuxbrew isn't great. Recommend nix instead.
A large number of perfectly good Apple machines are blocked from upgrading past El Capitan. Because Homebrew has begun to break under El Cap, its usefulness is significantly diminished.
The project is very active, with commits almost daily and plenty of conversation in issues. This means that the app will see bugs fixed and possibly new features added.
There are warnings provided that apps found in brew should not be installed with brew cask (and vice versa). While the user is warned of this, mistakes can happen, which would be better to just see them avoided all together by not supplying duplicate apps.
Homebrew Cask allows you to install graphical applications through the command line, rather than having to go through the standard installation process.
E.g. brew cask install google-chrome
Every time your profile changes, you get a new generation of your profile and older generations are kept around, so you can easily (and atomically) revert to older version of your profile.
You can have different (probably overlapping) sets of software installed in two or more profiles that will be handled (changed, versioned, upgraded, reverted) independently. All software will be installed in the same /nix/store, so any overlaps between your sets will be physically installed only once.
Every time you install, delete or change anything you get a new fresh copy of your user environment (set of symlinks to files in /nix/store) that's stored in the same /nix/store and handled mostly the same way. Your "profile" (symlink to one of environments) is updated after everything else is ready, so you'll never end up in a half-finished state of your system.
Due to its functional nature, it can just download a binary package with the same hash if its available and it'll get the very same package as you'd build locally (to the last bit that is).
Nix treats packages like values in a functional language. Since they are built by functions without side effects they never change after they are built.
While the functional approach that Nix takes is great for sandboxing binary artifacts of packages, it seriously lacks any power in handling configuration files or user data. It's difficult to upgrade and downgrade files where semantics and syntax can change between versions. Especially in Debian/Ubuntu it can cause severe problems where the upgrade process blocks and the user needs to resolve the 3-way merge.
MacPorts eschews Apple-supplied libraries and links sources against its own making sure that the experience is the same regardless of what OS X version is used.
Macports isn't the first choice for developers producing new packages or binaries for macOS. Nor is it the fastest in getting updates. But in general, it usually is one of the most up to date and will be updated eventually. Some would see this as a con in comparison to Homebrew.
Written in Tcl & C, it's generally significantly faster than the competition. Tcl is also quite readable and comparable to Ruby, so it's also friendly to newcomers.
Reading the story behind MacPorts, it is the only one that was developed by Apple by an Apple employee. In fact it is the same person that was responsible for creating the FreeBSD port system.
MacPorts has a habit of pulling very specific versions of dependencies for each package. It downloads different version of already existing dependencies even in cases where the existing dependency version would have worked seamlessly.
For example, trying to install Finch using Pkgsrc doesn't work, while installing it using MacPorts works perfectly. Finch isn't even on Homebrew's radar.
As MacPorts eschews Apple-supplied libraries and links sources against its own a large duplication of functionality across MacPorts and Apple libraries can be found.
pkgin aims to be a tool similar to apt/yum for managing pkgsrc binaries by relying on pkg_summary for installing, removing and upgrading packages and dependencies, using a remote repo.
Has been adopted to be used on several Unix-like operating systems and Windows. It's also the default package manager of DragonflyBSD and of the (now discounted) Bluewall Linux distro.
Installs its own dependencies which means that it is very secure. Cannot install anything unless you use the "sudo" command which is in keeping with the Unix philosophy.
Fast software installation is possible by using binary packages. It's also easy to build from source which allows for different compile-time options (like different UI backends) as well as gaining access to pre-release versions of software in certain cases.
Backporting fixes can be done by cherry-picking updates from a newer branch (pkgsrc is released every 3 months) and creating a package. Sometimes bugs need to be fixed for production and there is neither a fix in newer pkgsrc nor the softwares upstream. So pkgsrc has tools like pkgdiff, mkpatches, etc. that help with developing patches and building binary packages from that. A bit of documentation about that process can be found here.
Although Rudix is in development since 2005, there's a distinct lack of packages available. This limits the usefulness of the package manager for the user.
Using statically liked packages allows each package to contain all of the dependencies it needs, this way the user just installs to then use the app. No muss no fuss.
It happens often that the user will come across out of date, pre-compiled packages. This can impede on using new features released in apps due to using older releases.
Nix allows the creation of project-specific shell and build environments which are isolated from the rest of the system. These environments are defined declaratively to ensure reproducibility.
Because of the functional approach it takes, Nix makes it easy for systems to use multiple versions of the same package simultaneously, and ensure that updating or removing a package can't break other packages.
Nix is a purely functional package management system. This means that the act of building a package does not have side effects, such as destructively updating or deleting files that may be used by other packages.
When using Nix with anything other than NixOS you can run into difficulties with trying to start up services. For example, you can install docker with Nix, but it won't integrate with the host system's systemd leaving you to handcraft awkward workarounds in order to start the background service that docker requires. This seems like a critical flaw when using Nix on anything that is not NixOS, and it's unfortunate because this affects many of the packages many users would be most interested in using Nix to handle.
While the functional approach that Nix takes is great for sandboxing binary artifacts of packages, it seriously lacks any power in handling configuration files or user data. It's difficult to upgrade and downgrade files where semantics and syntax can change between versions. Especially in Debian/Ubuntu it can cause severe problems where the upgrade process blocks and the user needs to resolve the 3-way merge.