Option to use MacPorts (as well as other package managers)

[ylluminarious]

It would be nice if this script could use MacPorts instead of Homebrew. Or other package managers, too; including Fink, Nix, pkgsrc, etc. I've found that MacPorts has a significant number of usages and areas in which it is superior to Homebrew. Other package managers are also tailored for special paradigms. It would be nice if people who use this script could use it with their preferred package manager, rather than being forced to use Homebrew.

[pkill37]

For a while I considered using other package managers for this project, but I settled on brew because it was more popular and it meant I didn't have to invest a lot of time researching and testing the other package managers.

This would be a cool nice-to-have, but I honestly don't have the time to do this by myself. If I could get some help, I might reconsider.

However I'd be willing to rewrite the script for another (single) package manager, but only if there are significant advantages to it. Do you have an opinion on that? Which is the best package manager and why?

[ylluminarious]

@fabiomaia I think there could be significant advantages to any of the aforementioned package managers, depending on your use-case. I hesitate to say which is "best" because what's best for me might not be best for someone else. Rather, I'd like to do some light compare-and-contrast to show which ones might be best for which use-case and why. And then I'd also like to say which is best in my experience.

• Fink is nice because it emulates Debian-style apt-get package management. This is nice for people coming from the Linux world who see a familiar system in Fink. It's surprising that it didn't become the popular option for OS X package management, but popularity is determined by marketing (which Homebrew has done very well).
  • Unfortunately, since Fink is not that popular it can lag a bit behind other package managers and its developers are perhaps spread thin.
• Nix is nice because some Linux people are also familiar with Nix. This can likewise help people coming from Linux. Nix also offers a unique paradigm, with some features that are not found in some package managers. It seems quite lively and has enjoyed some decent marketing.
• pkgsrc is friendly to people coming from NetBSD. It offers a large package selection (not as big as MacPorts or Fink, but all are far bigger than Homebrew). I don't know much else about pkgsrc except that it's very cross-platform and thus is popular beyond the BSD world.
• MacPorts was where Homebrew is a while back. However, this is not due to technical inferiority of MacPorts. I really think it is largely due to marketing on Homebrew's part. Now, this is not to say that Homebrew is totally inferior to MacPorts in every regard, but I think in many important respects the two are on par or MacPorts is better. Some examples:
  • Homebrew does not allow you to install or easily use an old package version. It always tries to force you to use the latest or install the latest. This is not always desirable (bugs in the new version of an app, etc.) and this is much less of a problem in MacPorts.
  • Homebrew does not support root access at all. Root access, despite its risks, is exceptionally useful and necessary sometimes. Users should at least be given the freedom to shoot themselves in the foot, even if it is ill-advised. I have seen it where Homebrew does a totally normal operation, e.g. brew prune, and then fails with Permission denied errors. If you need root access to run these out-of-the-box commands, well it's off to the sources with you. You have to modify your Homebrew installation and that can be sketchy at best. This is all discouraging in multi-user environments, which subsequently require separate accounts or groups. This can be even sketchier should things go awry.
    • MacPorts totally avoids this issue by explicitly using root access to do things. At the end of the day, if you can't trust your package manager with root access then you really can't trust it at all. After all, you can still get badly pwned even if you avoid root access. There are plenty of attacks which do not rely on root access. If your package manager is doing something funky with its privileges then your problem is deeper than root access.
  • Homebrew does not quite support installing to places outside of /usr/local. I know that this is considered a Good Thing, but there are plenty of arguments against it. They do not need to be enumerated here.
    • MacPorts allows different installation prefixes and is already out-of-the-way by default. /usr/local is used by lots of things for lots of different purposes and sticking your package manager in there is not necessarily a good idea (and again, many think it's an outright bad idea esp. in the Linux world). /opt/local is much more out-of-the-way and easily accessible simply by appropriately setting PATHs and so forth.
  • Also, Homebrew actually has the smallest package selection on OS X, when compared to MacPorts or Fink. These other package managers have several times more packages in the core repositories than Homebrew. But the Homebrew maintainers seem to be pretty strict nowadays, which leads to lots of "taps." Taps are hard to find, not guaranteed to work or to be maintained at all, can go totally stale, and are generally unappetizing. The Homebrew maintainers are fine with this, but MacPorts folks are more inclusive and less strict in certain regards.
  • MacPorts also allows patches to be included with packages, which can really help programs in the long-run.
    • Homebrew maintainers are vehemently against patches and frequently kick out programs which are too "old" or which have patches. This is a real shame, and there is often no reason for this except that a given package is old and not very popular (as a side note, Homebrew also frequently removes APIs breaking many taps and other tools; they do not have much respect for backward compatibility). MacPorts is far better in this regard.
    • Unfortunately, some MacPorts packages have to be compiled from source because of the use of patches. But this is often not very long and many packages can be installed as binaries with no problem. When patches are used, it's often for a good reason and can help program stability or whatnot.
  • MacPorts also offers other distinct advantages like a REPL, good scripting environment (Tcl, which is a lot like Ruby, i.e., it is a nice language), it's fast because it's written in Tcl & C, it offers much more fine-grained control than Homebrew, it has thorough documentation which far outshines Homebrew's, and it's not tied to the OS unlike Homebrew (i.e., if Apple makes a big controversial change MacPorts is less likely to be affected because it's more independent to the system).

All in all, this is coming from someone who converted to MacPorts after being a long-time Homebrew user (and contributor). MacPorts is just much more user-oriented in my opinion; it cares about making a user happy and gives him more control to do so. Homebrew is more concerned about making you not shoot yourself in the foot, because that's too big of a headache for the maintainers. But MacPorts has gone along just fine while rejecting this somewhat apathetic philosophy of Homebrew and MacPorts is still quite active.

So, in my opinion, MacPorts is the best package manager for OS X. But I can see where other package managers like Fink, Nix, and pkgsrc can have usefulness and desirability. Unfortunately, I really don't see where Homebrew offers advantages over these other solutions. The only thing where it seems to have an advantage is that it's written in Ruby, but with so many APIs being removed constantly and in light of the fact that MacPorts uses Tcl which is a very comparable & nice language, this too seems to not be a big advantage. Also, the use of Ruby makes Homebrew noticeably slower than the competition. Sadly, Homebrew seems to have really been a champion in marketing and not much else. And this is coming from someone for whom Homebrew was his bread & butter!

Sorry for the long wall of text! But in all fairness, you asked a very loaded question xD

[pkill37]

That was very enlightening. I am inclined to agree with you that MacPorts is better and Homebrew only won because of marketing.

But there is something to be said about popularity. For example just now I was looking into using Time Out, but it's not available on MacPorts. In fact I can't even seem to find Chrome or Firefox. Does it only distribute open-source or CLI software or something?

[ylluminarious]

@fabiomaia Yes, both MacPorts & Homebrew only distribute open-source software. To quote from Homebrew's docs (emphasis added):

Our policy is that formulae in the core tap (homebrew/core) must be open-source and either built from source or produce cross-platform binaries (e.g. Java, Mono). Binary-only formulae should go to Homebrew Cask.

And to quote from MacPorts' homepage (emphasis added):

The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac operating system. To that end we provide the command-line driven MacPorts software package under a 3-Clause BSD License, and through it easy access to thousands of ports that greatly simplify the task of compiling and installing open-source software on your Mac.

The reason being (I think) is to avoid legal complications and to prevent from distributing malware or other questionable software. Plus, these package managers fill a niche. It's not like there are a whole awful lot of solutions for easily installing open-source software on a Mac. So distributing proprietary software just isn't a concern for anyone here. After all, the App Store & MacUpdate exist for a reason ;)

I think (although don't quote me on this) that the other package managers also avoid proprietary software, or that if they do ship it, then it is exceptional. In fact, the only package manager for OS X which I know of that distributes proprietary software is Homebrew Cask which is not part of the Homebrew Core and is somewhat of a separate package manager (although it's included with Homebrew's installation).

[pkill37]

Lately (#19) Homebrew has been getting on my nerves. The install locations are an always changing confusing clusterfuck, there are seemingly unnecessary cascades of symlinks, and the caveats info is inconsistent and usually out-of-date. Maybe it's just me (doesn't help that I don't know Ruby thus reading the source doesn't give all the answers), but it is not easy to understand and it makes it really frustrating to maintain what should be a very simple script like this.

@ylluminarious Is MacPorts simpler and more consistent in this respect? I've only read a little bit, but the install page seems to indicate that it is much simpler.

You will need to manually adapt your shell's environment to work with MacPorts and your chosen installation prefix (the value passed to configure's --prefix flag, defaulting to /opt/local):

Add ${prefix}/bin and ${prefix}/sbin to the start of your PATH environment variable so that MacPorts-installed programs take precedence over system-provided programs of the same name.
If a standard MANPATH environment variable already exists (that is, one that doesn't contain any empty components), add the ${prefix}/share/man path to it so that MacPorts-installed man pages are found by your shell.
For Tiger and earlier only, add an appropriate X11 DISPLAY environment variable to run X11-dependent programs, as Leopard takes care of this requirement on its own.

@ylluminarious As a MacPorts fan and ex-Homebrew contributor, do you think MacPorts wins in this department? If so I'm all in.

[ylluminarious]

@fabiomaia I understand your frustration with Homebrew and believe me, you're not alone. They've been turning off lots of people lately and it's really a shame. They actually banned me from their repositories due to a comment I made on an issue. They are becoming increasingly irrational. They even removed build options in all core formulas in Homebrew 2.0. On both the technical and diplomatic fronts, they are making blunder after blunder and it's turning people away from Hombrew, more than they'd like to admit.

Anyway, my personal frustrations with Homebrew aside, yes I do think MacPorts does better in a number of regards which you mention. First of all, the symlinks issue does not exist in MacPorts. It tracks which files are installed by which port at installation time, and thus does not need to box everything into its own folder (as Homebrew does).

The quote you reference from the installation page is accurate. All in all, I think MacPorts would be much better for your program, which essentially aims to replace system utilities or at least overshadow them. This would be a BIG no-no for Homebrew's maintainers, and they would not care to support such a use case at all, whereas MacPorts has a far more agnostic philosophy. The only disadvantages which I can ascribe to MacPorts as opposed to Homebrew (after using it for about a year) is that it can be somewhat more difficult to use sometimes (although the documentation is superb and extensive) and that, obviously, Homebrew is more popular than MacPorts which means that Homebrew has an advantage in manpower. But Homebrew seems to be losing ground on this point because they are being more and more rude and despotic.

If you would like me to specify further on any particular points, please ask away.

[pkill37]

Manually maintaining the environment variable exports for every program requires a lot of work and isn't very future-proof

https://github.com/fabiomaia/linuxify/blob/master/.linuxify

If switching to MacPorts means this can be done more generally with just a few exports, I'm all in. My main issue with the switch was that brew is much more popular (thus more practical in some sense), but I guess it's reasonable that MacPorts is assumed for this script and users can still use brew for their own purposes.

@ylluminarious What do you think?

[ylluminarious]

@fabiomaia Apologies for the year-late reply. I believe you'd have significantly less environment variable exports using Macports than what you have in that file. My own .zshenv contains exports only for the following:

export PATH="/opt/local/bin:/opt/local/sbin"
export PKG_CONFIG_PATH="/opt/local/lib/pkgconfig:/usr/local/lib/pkgconfig"
export PATH="$PATH:/opt/local/lib/postgresql11/bin"
export MANPATH="/opt/local/share/man"
export SSL_CERT_FILE=/opt/local/etc/openssl/cert.pem

Generally, though, most everything tends to live under /opt/local/bin and sbin.

[pkill37]

@ylluminarious Thanks for the input! I'm strongly considering rewriting the script to install packages from MacPorts.

What's this SSL_CERT_FILE environment variable though?

[ylluminarious]

@fabiomaia For me, that is required for certain things in Ruby to work properly, like gems and some other things (including wget sometimes). That just sets it to the location where I install it with this package. You can just ignore it if you wish.

[testfailed]

I think nix is fairly fundamental option and well conformed with this project's ultimate goal. It builds literally everything for a variety of architectures and it has the largest community for it. People using nix are in need of projects like linuxify and are happily willing to contribute for it as well.