
Thoughts on macOS Package Managers - pplonski86
https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/
======
notafraudster
Not to pile on, but I thought Homebrew handled the Python2 -> Python3 cutover
poorly. A routine `brew upgrade` resulted in python being de-syslinked. For
me, this meant a bunch of tasks broke silently in the background. It took a
little while to find out that it was just the case that `python3` became the
default interpreter and thus I needed to install some dependencies for scripts
running in the background.

It's totally fine as my code was python3 compatible, but I was surprised that
they'd apply a breaking change like this silently. Unlike OSes which might do
this kind of thing with a major version update, I was surprised, and it took
me a little while to diagnose what happened.

When I checked the GitHub discussions about the change, I found two things: 1)
The maintainers claimed they had given a soft deprecation message a few months
prior -- but brew doesn't stop for user input, it just posts walls and walls
of messages, so I had naturally tuned it out. 2) The maintainers were getting
ballistic mad at people who didn't think this was handled well.

Of course, open source is open source, and maintainers owe us nothing, but I
was surprised that such a critical piece of infrastructure was being managed
by people who imho handled a potentially non-trivial transition like this and
who clearly didn't have the diplomatic tact to handle their userbase.

~~~
csande17
Yeah, Homebrew tends to not handle upgrades very well, especially around major
versions -- I remember when their decision to change the "qt" formula from Qt
4 to Qt 5 broke pretty much everyone who had it installed.

Part of the problem is technical--IIRC they don't have any CI infrastructure
to test upgrade processes--but mostly they just don't care. They'd rather have
the cleanest, most elegant code today, even if it means breaking everyone who
installed it yesterday. That philosophy makes sense for a lot of projects
(like in SaaS, where you often deploy new versions by creating new virtual
machines and installing everything from scratch), but I'm not sure it's the
most productive way to run a package manager.

~~~
rmc
> _That philosophy makes sense for a lot of projects (like in SaaS, where you
> often deploy new versions by creating new virtual machines and installing
> everything from scratch),_

Does that ever happen with OSX.....

------
iElectric2
I'm pretty sad it doesn't explore Nix as it's superior in isolating and
doesn't require root.

Getting started: [https://medium.com/scientific-breakthrough-of-the-
afternoon/...](https://medium.com/scientific-breakthrough-of-the-
afternoon/improving-quality-of-life-on-mac-with-nix-package-manager-
beb08e96849a)

How much effort was put into making the whole isolation:
[https://www.youtube.com/watch?v=73mnPBLL_20](https://www.youtube.com/watch?v=73mnPBLL_20)

There is even a declarative way to setup darwin process management:
[https://github.com/LnL7/nix-darwin](https://github.com/LnL7/nix-darwin)

~~~
SkyMarshal
/second Nix on OSX. In addition to your reasons, it doesn't depend on the Mac
community for growth and support as Homebrew and MacPorts do. Regardless how
many OS X users use it, its bread and butter is NixOS and the Linux server
community.

~~~
viraptor
Does nix on osx allow you to manage/upgrade native osx packages?

~~~
patrec
I thinks so, e.g. `nix-env --install --attr nixpkgs.emacsMacport`. But there
isn't a huge selection of native macOS GUI apps.

------
twblalock
I moved to Homebrew a few years ago because MacPorts was significantly slower
in adding new versions of some of the packages I needed to use for work. I had
resisted using Homebrew until that point because the architecture of MacPorts
made more sense to me, and because Homebrew's permission model in /usr/local
is terrible.

At this point it seems like Homebrew is the standard -- I frequently see open
source projects recommending it in their installation instructions without
mentioning Macports.

I also recommend Homebrew to friends and coworkers, for the reasons I already
mentioned, and also because it is significantly easier to install. Go to their
website and the first thing you see is an installation script. Go to the
MacPorts website and you see a link to an installation page partway down. That
installation page is very long and lists a number of prerequisites needed for
the installation to work. Homebrew does the installation bit way better, thus
making the barrier to entry far lower.

MacPorts would need to demonstrate significant advantages over Homebrew to get
me to switch back.

~~~
aisofteng
As someone who switched to MacOS for work a few years ago for a new job out of
a desire to not have the fudge with Linux for getting work done at work, I
thought MacPorts was obsolete based on what I found online about installing
packages and so on.

~~~
saagarjha
I thought so too at first, but it's not! It's maintained relatively actively
([https://github.com/macports/macports-
ports/commits/master](https://github.com/macports/macports-
ports/commits/master)), so I think this perspective is mostly just a result of
Homebrew having better marketing/more people using it.

------
GlenTheMachine
I used to use MacPorts, and switched to Homebrew. For exactly one reason:
Homebrew uses, whenever possible, the tools already built in to macOS, where
as MacPorts builds new versions of those tools in order to maintain a pristine
build environment.

MacPorts' philosophy seems better in theory, but in practice it has two flaws
that turned out to be very significant for me. The first is that you end up
needing a huge number of ports, partly because you're duplicating the tools
already on the system, but partly because in many cases you need all of those
ports' dependencies as well. So upgrading anything was a huge processing sink.
I wanted fifteen or twenty ports on my system, but to get those MacPorts had
to install several hundred dependencies. If you ever decide you _don 't_ want
one of those ports, the dependencies are still installed, and pruning the
ports tree was decidedly nontrivial.

The second was dependency hell. You end up with at least two versions of
everything. Which one random third party apps pick up depends on search paths.
Different third party apps need different versions, and I ended up twiddling
with search paths a lot. Tryin to install ROS as a standalone third-party
package was a nightmare.

Homebrew has its issues, but it doesn't have _these_ issues.

Ultimately the real problem here is that macOS package managers are bolt-on
additions and not a core part of the OS. when that's the case there is not
going to be any perfect solution. But for a single-user machine where the main
goal is to be able to maintain a minimal set of installs, and install new ones
quickly so you can get real work done, Homebrew just worked better for me.

~~~
natecavanaugh
You hit the nail on the head why I had gone from MacPorts to Homebrew, and for
me, the extra need for sudo was just an additional pain point.

Your last point brings up an interesting question in my mind regarding Apple's
intentions for the CLI. On the one hand, they seem to care enough to add
features here and there to Terminal, but then when you consider that the tools
have basically zero chance of upgrades being incorporated for licensing
reasons, I wonder if they plan to even have a stance on package managers, or
if they are completely fine with that being purely in user land. The entire
CLI experience on macOS concerns me in as much as the OOTB set of tools will
continue to work, but how much more fragmented will the experience get?
There's already a good chance at running across some shell code online that
requires bash 4 or relies on a newer gnu version of a tool. Maybe this long
tail of developers is too niche for Apple, but I imagine it's still important
to many of their developers in some way.

------
Doctor_Fegg
Good piece.

Homebrew is certainly "opinionated" and, as the article says, "abrasive".

I recently had one of those upgrade chains: new iOS needs new Xcode, new Xcode
needs new OS (Mojave), new Xcode and OS need new Boost. All fine up to this
point.

I'd installed Boost via Homebrew. So, fine, brew upgrade boost.

A bunch of stuff scrolls past... holy ---- it's upgrading Postgres?

Oh great. Now a whole bunch of work I have stored in a Postgres database is
inaccessible. No problem, Homebrew apparently has a Postgres upgrade script
now.

Except it wouldn't work, complaining "no upgrade path" from PostGIS 2.4 to
2.5.2; and Homebrew wouldn't install both at the same time. Eventually, after
much experimentation, I found Postgres.app came with all the right versions,
allowing me to pg_dump it all out.

But my word... while trying to figure this out I spent hours looking through
the issue tracker, and the state of it. Endless snark about "we don't support
old versions". Fun like this:
[https://github.com/Homebrew/brew/issues/5675#issuecomment-46...](https://github.com/Homebrew/brew/issues/5675#issuecomment-461439973)

It's a good tool, just don't expect any support with it, ever. I kind of feel
that Homebrew's slogan should be "Homebrew locked as resolved and limited
conversation to collaborators".

~~~
andreareina
Yup. Installed something, which installed a new version of readline, which
caused the old version to become garbage collected despite still being in use
by other things I've installed in the past. I'm _still_ finding things that
don't work anymore due to a dylib being gone, and god help you if you're
running an older OS version that's not supported by a core dependency (hello,
qt).

------
kelsolaar
Homebrew maintainers editing other people comments is intolerable:
[https://news.ycombinator.com/item?id=19066630](https://news.ycombinator.com/item?id=19066630)

~~~
tschwimmer
Why does GitHub allow anyone to edit other people's comments? I could imagine
an extremely limited number of scenarios where it would be useful and many
where it would be harmful.

~~~
uranusjr
First, only anyone can edit other people’s comments; only repository admins
can edit messages in the repository. Also, anecdotally, it is overwhelmingly
positive to me, only harmful in extremely limited number of cases (this be one
of them). Many people don’t know how to use Markdown (probably don’t bother to
learn) and produce gibberish issue reports. Those would have been difficult to
manage if edit were not allowed. Sure, it is possible to do without edit, but
it’s the same the other way around (GitHub does keep edit history).

~~~
ilikehurdles
Github may keep edit history, but it seems like maintainers have the ability
to remove previous edits of comments entirely, as is the case in the linked PR
(perhaps it's limited to Enterprise?)

I don't like this. A maintainer can fake another users' comments for some very
nefarious purposes.

~~~
justinclift
Yeah, it's an optimistic biased system, but it's a decent practical approach.
The cases of maintainers being lousy seems pretty uncommon.

AFAIK the reason maintainers can completely remove revisions of comments, is
because occasionally a well intentioned user pastes sensitive info into a
comment and doesn't realise.

While pointing it out to the user so they can remove it themselves does work,
that's an unbounded time frame (perhaps never). So just nuking it directly is
"safer" in that instance.

Doesn't seem like there's any really perfect solution.

------
mnm1
Homebrew isn't great but having to manually remove and reinstall all macports
every os upgrade, having to deal with messed up dependencies and debugging
failed compiling errors manually, and having macports libraries conflict with
other mac software and making it crash was just too much. I need at best a few
tools provided by these package managers and I don't want to spend hours
messing around with their configurations. I just want them to work. Brew used
to have issues for me but the last couple of years it's been the least buggy
experience. That's all that matters. I don't give a fuck if it uses sudo or
not, where they store files, or even if I have to disable system protection.
All that is simply irrelevant. I just want things to work so I can get my
actual work done. That is what makes a package manager better and that's why
brew these days is much better than macports.

~~~
kitsunesoba
Precisely, the goal is to do a quick 'manager install foo --bar' when called
for an move on with life.

------
asveikau
Something has always rubbed me the wrong way about homebrew. I feel like there
is something about it that doesn't quite jive with Unix philosophy. It doesn't
feel like a Unix tool, vague as that sounds. Assuming ownership of /usr/local
as this author complains is along those lines.

It just always seems like between "just get it kinda working" and "work how I
expect" it often picks the former.

~~~
SllX
It’s a Macintosh tool for Unix users. Or a Unix tool for Macintosh users, can
never decide. At least that is how I’ve always explained the weirdness to
myself.

~~~
asveikau
Sure, but macports always seemed more unixy.

Then there's fink mentioned in the article which was popular long ago which
literally was a port of Debian stuff.

At some point I was using pkgsrc from NetBSD.

So a more Unix person's type of tool exists.

------
overgard
Reading those homebrew comment threads convinced me to switch to MacPorts. I
don’t care if you’re a volunteer, that’s not how you treat users.

~~~
Hackbraten
Homebrew maintainer here. Yes, there have been complaints of poor
communication back then, and I feel those complaints were justified.

But we’ve also said we’d improve [1] and I feel that the effects already show
[2] [3]. We’ve been communicating changes earlier and more clearly lately.
We’ve learned a lot from user feedback, and we’re nowhere near the end.

Sad to see you go though! Happy to welcome you back anytime.

[1]:
[https://github.com/Homebrew/brew/issues/142#issuecomment-214...](https://github.com/Homebrew/brew/issues/142#issuecomment-214850970)

[2]:
[https://twitter.com/MacHomebrew/status/1119288776830926850](https://twitter.com/MacHomebrew/status/1119288776830926850)

[3]:
[https://twitter.com/MacHomebrew/status/1119502934000029696](https://twitter.com/MacHomebrew/status/1119502934000029696)

------
actionowl
Shame there is no mention of pkgsrc, I've been using it for years.

[https://pkgsrc.joyent.com/install-on-osx/](https://pkgsrc.joyent.com/install-
on-osx/)

------
hasahmed
Great article. Really puts into words many complaints I have against Homebrew.
The non-sudo thing doesn't bother me, its the leadership. User-hostile is
definitely the way to put it. I don't anticipate leaving Homebrew any time
soon, but it sure would be cool if the maintainers were nicer. A favorite
thing to say is that they don't owe the users anything, but I think that they
forget that a lot of users are contributors too. And they would probably
contribute more if the maintainers were a little nicer.

~~~
Hackbraten
Homebrew maintainer here. Thank you for your comment and for being sincere.
I’m sorry you feel that way about user-maintainer relations. While I respect
your feelings and think they are valid no matter what, would you mind linking
to one or two recent examples? It’d definitely help to have a look at concrete
instances where our actions felt hostile to you so we can figure out how to
improve.

Everyone who interacts with the Homebrew community must be treated with
respect, no exceptions, and if we maintainers suck at that then we need to be
better.

------
qalmakka
As much as homebrew has its flaws, I don't want to use MacPorts until it
supports binary packages as well as building from source. It's something even
FreeBSD understood; not everyone is running on 8 core machines, and I don't
have the time to build GCC or LLVM on a midrange laptop CPU. No one I know
uses Homebrew because it's awesome, but because they wouldn't even consider
for a split second a solution that involves waiting for hour for stuff to
finish building from source.

~~~
manwe150
That's been true since 2012 ([https://lists.macports.org/pipermail/macports-
announce/2012-...](https://lists.macports.org/pipermail/macports-
announce/2012-May/000021.html))

------
rswail
When I moved from Linux to Mac (started iOS development and got sick of
tinkering to get stuff working), I looked at both homebrew and macports.

As soon as I saw that homebrew wanted to use /usr/local instead of /opt, I
avoided it. These days, /usr is part of the system, even though GNU still uses
/usr/local as the default.

/opt matches where the LSB says "3rd party packages" should be installed,
MacPorts is (or was) partly sponsored (and thus "blessed") by Apple and it
matches the "port" packager that is used for FreeBSD.

Yes you have to do some PATH and LDPATH tricks to make sure that /opt/local/*
is at the top of your paths, but other than that, MacPorts has been painless.

There are some steps to follow when a new version of Xcode (and effectively a
major release of MacOS) comes out, but that's more about getting xcode to
accept you've accepted Apple's license.

------
internet2000
Homebrew removing options is such a silly thing. Changes nothing in the end
result, just makes things a more inconvenient.

------
lelf
There’s also [https://pkgsrc.joyent.com](https://pkgsrc.joyent.com) (yes, for
MacOS too).

------
nisuni
Great article, having used both package managers I can relate. Neither one is
perfect, but MacPorts tends to be FAR more reliable.

> MacPorts almost always builds packages from source

That’s a misconception. As of 2019 a properly-configured MacPorts will
download almost exclusively binaries.

------
fouc
Why not use Nix package manager if you're looking for an alternative to
homebrew?

~~~
aisofteng
Is this viable without tinkering on macOS?

~~~
iElectric2
Yes.

------
csande17
My personal beef with Homebrew is the amount of work they create for third-
party "tap" (package collection) maintainers by constantly making breaking
changes to the formula interface.

For example, Homebrew used to support compiling on both 32-bit and 64-bit
systems. They provided a "is 64 bit" function that packages could use to check
if they were being compiled on a 64-bit system. It worked great!

Then, Homebrew decided they no longer wanted to support 32-bit systems.
Instead of doing what any reasonable project with a stable interface would do
and modify the "is 64 bit" function to always return "true", they just deleted
it! I found out when one of my users emailed me to let me know that my
packages crashed when you tried to install them.

Changes like these mean that I spend 20% of my package-maintainer time on real
work and 80% dealing with Homebrew's nonsense. Moreover, they show that
Homebrew doesn't care at all about the people who maintain packages outside
homebrew/core. And as someone who maintains packages outside homebrew/core,
that makes me not want to continue.

------
h1d
Can't use Homebrew for any stable operations.

I had a project that has Ruby set at version 2.5, one day Homebrew turned it
into 'ruby@2.5' and now 'ruby' was 2.6 and whenever @2.5 also upgrades, since
there is no global symlink, a minor version change breaks my IntelliJ setting
as the path has slightly changed.

I was using Ansible from my local Mac but dropped it thinking this might just
break one day. Linux distribution vendors do far better jobs at keeping things
'as is' for years.

The only use for Homebrew for me is to install individual tools that don't
have wider impact if it breaks (like ripgrep).

------
jonhohle
I’ve always get off about Homebrew, but never put words to it. Many of the
comments here seem to mirror my feelings.

From the beginning it was as if no package managers had ever existed and they
were solving packaging problems for the first time ever and ignoring not just
the other Mac package managers but other package managers in general.

Then there’s the smattering of cutesy names for internal concepts: bottles and
casks and tapping.

Popularity of Homebrew skyrocketed, though.

Meanwhile, MacPorts is better than ever.

~~~
Hackbraten
About the cutesy names: yes, that was probably a mistake. We’ve looked into
fixing this but I feel it’s too late to change the terminology now without
causing even more confusion.

Glad to hear MacPorts works well for you! Should you ever decide to come back
to Homebrew, we’ll be there for you.

~~~
PascLeRasc
I'm unaware of all the drama everyone else is referring to and I'd like to
remain ignorant, but I really prefer the naming scheme. It's more intuitive to
folks like me for whom Homebrew is our first package manager, and it really
helped me understand why things are how they are in package managers in
general. I appreciate a little whimsey in software.

~~~
Hackbraten
Thanks for the feedback. That’s insightful!

In software, I’ve always preferred the more serious tone. No idea why; I love
silliness and monkeying around in general.

------
paultopia
The permissions black magic is really upsetting to me---undoubtedly, I freely
and openly admit, because I don't really understand permissions, but it seems
to engage in behavior that it shouldn't be able to engage in. As recounted in
this old blog post[1] it does things like change the permissions on its own
files even after one declares the owner to be root and sets the file as non-
writeable. Now, like I said, I don't really understand how file permissions
work, so I'm sure that there's a perfectly logical explanation for how that's
possible---but it hardly seems consistent with the incessant claim the
homebrew maintainers make that it doesn't require elevated privileges.

[1] [https://paultopia.github.io/posts-output/anti-
homebrew/](https://paultopia.github.io/posts-output/anti-homebrew/)

~~~
saagarjha
To be fair, MacPorts will also ask you to have the latest Xcode, though many
(dare I say most?) packages will install without it. But I do think that
Homebrew's permissions are pretty broken. Apparently macOS does too, since
it'll reset them (and make Homebrew unhappy) if you do a reinstall.

~~~
rswail
My understanding is that MacPorts requires Xcode to have the Apple clang
compiler available. I don't think that's a particularly awful requirement.

~~~
saagarjha
You can get reasonably far with the Command Line Tools, which contain clang.
Xcode is only necessary for some (few, in my experience) packages.

------
justinclift
Interestingly, they now seem to have ~US$3k/month via Patreon:

[https://www.patreon.com/homebrew](https://www.patreon.com/homebrew)

Wonder if they'll use it for paying maintainers or something? It's a useful
amount for planning things out with. :)

~~~
shorsher
In a recent podcast I listened to on The Changelog [0], I’m almost positive
Mike McQuaid (homebrew creator/maintainer) talks about how they use that money
when they cover Homebrew governance.

0:[https://changelog.com/podcast/337](https://changelog.com/podcast/337)

~~~
justinclift
Thanks, it was interesting. :)

As a minor data point, the creator of Homebrew was Adam Vandenberg, not Mike
McQuaid:

[https://github.com/adamv](https://github.com/adamv)

~~~
sansnomme
Incorrect, it's Mike Howell (the invert binary tree guy)

~~~
malmckay
Max Howell

------
l2dy
Disclaimer: I'm a MacPorts committer.

> MacPorts almost always builds packages from source

Many packages in MacPorts (including LLVM) have pre-built binaries available
from [https://packages.macports.org/](https://packages.macports.org/) and its
mirrors for macOS releases ranging from Mac OS X 10.5 to macOS 10.14.

But if a port is considered not distributable because of its restrictive
license or license conflicts with dependencies, binaries will not be uploaded
to our official mirror so users have to build it from source. We don't provide
official binaries for non-default variants or alternative prefix (the default
is /opt/local) either, but organizations using MacPorts can set up private
mirrors with custom ports and binaries.

port_binary_distributable.tcl[1] describes the license conflicts. e.g. "git"
is not distributable because its license "gpl" conflicts with license
"OpenSSL" of dependency "openssl".

> MacPorts seems to be a bit lacking in manpower (which makes things takes
> slightly longer than I would have expected)

Yes, we need more contributors and committers to maintain the large collection
of ports we have. Our ports are more often outdated than Homebrew because of
this and our maintainer policy. We are also seeking for ways to improve our
developer experience, e.g. [https://github.com/macports/macports-
base/pull/120](https://github.com/macports/macports-base/pull/120) which
automates updating checksums in the Portfile.

> The lack of color, as well as somewhat more cluttered and less relevant
> output, makes it a bit less pleasant to work with.

We talked about this in a meeting last year, but it hasn't been implemented
yet.
[https://trac.macports.org/wiki/Meetings/MacPortsMeeting2018/...](https://trac.macports.org/wiki/Meetings/MacPortsMeeting2018/UserExperience)

Development of the port command is relatively inactive (severe lack of
manpower). [https://github.com/macports/macports-
base/commits/master](https://github.com/macports/macports-base/commits/master)

> MacPorts will set up its own tools in isolation from those provided by the
> system

Its own versions of libraries, to be exact. See
[https://trac.macports.org/wiki/FAQ#syslibs](https://trac.macports.org/wiki/FAQ#syslibs)
for more background on this.

> builds run in “sandboxes” under the macports user, where attempts to access
> files outside of the build directory–which includes system tools–are
> intercepted and blocked

It will block writing files outside of directories specified in
portsandbox.tcl[2], but using (reading and executing) system tools is allowed.
For example, most ports are built with the compiler from Xcode.

> The upside is that this approach is significantly more contained, which
> makes it easier to manage and more likely to continue working as macOS
> changes under it.

Yes, but we recommend users upgrading to a new major release of macOS
reinstall MacPorts and all ports because things could still break. We have a
migration guide here:
[https://trac.macports.org/wiki/Migration](https://trac.macports.org/wiki/Migration).

[1] [https://github.com/macports/macports-
infrastructure/blob/mas...](https://github.com/macports/macports-
infrastructure/blob/master/jobs/port_binary_distributable.tcl)

[2] [https://github.com/macports/macports-
base/blob/master/src/po...](https://github.com/macports/macports-
base/blob/master/src/port1.0/portsandbox.tcl)

~~~
fluffything
> port_binary_distributable.tcl[1] describes the license conflicts. e.g. "git"
> is not distributable because its license "gpl" conflicts with license
> "OpenSSL" of dependency "openssl".

Why does this license conflict prevent from distributing the tool? The tool is
under the GPL, which requires making the source code available, which it is,
and it also allows linking against OpenSSL, which has its own rules, but none
seem to disallow distributing binaries that come with it.

~~~
l2dy
IANAL.

This article convinced me about the conflict:
[https://people.gnome.org/~markmc/openssl-and-the-
gpl.html](https://people.gnome.org/~markmc/openssl-and-the-gpl.html).

The OpenSSL license imposes certain restrictions on people wishing to
distribute their program using OpenSSL, while the GPL-2.0 license says you may
not impose any further restrictions when you redistribute the program. There
is an exception for OS components, but MacPorts is not part of macOS.

------
kkarakk
npm installation is broken with brew. had to use the standalone installer coz
none of the workarounds would add npm to the path correctly(brew has some
problems with access permissions and can't be sudo forced to get those
permissions)

kinda irritating

~~~
Hackbraten
Are you talking about the `node` package? That’d be strange because the
package definitely creates a `npm` symlink in /usr/local/bin and that has
always worked for me.

Care to elaborate a bit on the permission problems?

~~~
kkarakk
[https://gist.github.com/rcugut/c7abd2a425bb65da3c61d8341cd4b...](https://gist.github.com/rcugut/c7abd2a425bb65da3c61d8341cd4b02d)
it's this "known" unfixable issue and i was too lazy to do the workaround
properly(i want to work with node not spend another hour figuring out the
intricacies of node's interaction with brew) and googling online led me to the
simple solution of just installing the package from node directly.

big fail imo

------
exabrial
The sudo-less operation of homebrew bothers me greatly too :/

But I just want to say thank you very much to The Homebrew team, if you're
reading this, I really appreciate your efforts.

------
KiDD
I previously had many issues with MacPorts but I am certainly going to be
revisiting it.

------
brainfeed0
Where to begin. it's a Homebrew hit-piece extolling how the inaccessible and
system-modifying MacPorts is "superior." Bologna! I don't trust MacPorts, it's
old, confusing, has terrible UX and promotes system-entropy increase (read:
weird gotchas and eventual reinstalls). Leave my goddamn system alone. I don't
trust giving a community package sudo.. ever. I don't pipe bash into shell, so
no sudo for you either, mister package manager.

No sale.

~~~
saagarjha
> I don't trust MacPorts, it's old, confusing, has terrible UX and promotes
> system-entropy increase

MacPorts is old, but I think that's a good thing: it's robust and well
designed–at least compared to Homebrew, I feel. It's lacking a bit of color
and a few emojis, but usability isn't _that_ bad (in fact, I would say it has
fewer surprises, because commands usually do exactly what they expect you to
and nothing else behind your back).

> I don't pipe bash into shell, so no sudo for you either, mister package
> manager.

Sorry, what? I don't know that the first part means, and the second is
standard across almost every system package manager.

------
sirmike_
MacOS was not made for multi-users on one machine.

~~~
twblalock
Sure it was. That's why it allows multiple user accounts with a number of
privilege levels, and gives each user a separate directory tree for storing
documents etc.

------
FraKtus
Am I crazy to refuse to use a package manager on macOS? I thing that you
should just follow the instructions and understand how to install a project.
As an example, I use a lot FFmpeg, just doing brew install ffmpeg does not
make sense for me; there are so many options... you need to understand what
they are and the implications...

~~~
pjmlp
No, I also do not use one.

OS X already provides enough UNIX to my taste, no need to look beyond it.

Everything else I need is part of the SDK.

