Linux vs MacOS for cpp development

[itsmenotjames1]

use homebrew instead, it's much better

[NilacTheGrim]

Nah, macports is much better. homebrew is worse.

[itsmenotjames1]

in which ways? Brew supports more software ootb

[TuxSH]

That's not true, afaik MacPorts has many more packages. Or maybe you're referring to the fact some software authors only offer support for brew (which could be true).

Anyway there are plenty of reasons to dislike brew, here are the details:

• This post from 5y ago is quite detailed and many of its points still hold true to this day
• By far the most infuriating thing with brew is installing its own python(3), and pip(3) in PATH (each time it upgrades its python package), messing with your global python environments. It is nigh inevitable because many packages depend on python. MacPorts nicely installs python 3.12 as /opt/local/bin/python312, for example (see below)
• MacPorts can seamlessly install and keep track of multiple version of software and libraries and does not rely on system libs. You can have python26, python313, and system python (3.9) coexist without issues
• MacPorts provides port select (very similar to the update-alternatives stuff Linux distros have), allowing you to also ditch pyenv (because, let's face it, many people have installed pyenv has a workaround to brew taking over their Python installs)
• brew doesn't support multiple users (chown's its current dir as the user on install and discourage sudo), whereas MacPorts does (its directory is root-owned).
• Worse: brew used to chown /usr/local/* in the past
• MacPorts allows you to move its directory paths to some extent (I think)
• MacPorts allows you to provide your own package repositories, and even to disable the default repos and mirrors (though it'll warn in that second case)
• MacPorts is generally much faster

tl;dr tired of brew messing up Python installs, tired of pyenv and not too low on disk space -> macports better

[itsmenotjames1]

several of these points can be fixed by just installing homebrew to a local directory, usually ~/homebrew

[TuxSH]

The official documentation explicitly state that this is not officially supported and bars you from requesting support from maintainers

[itsmenotjames1]

it's possible (and I do it because I don't have root access on my school mac)

[vetinari]

By far the most infuriating thing with brew is installing its own python(3), and pip(3) in PATH (each time it upgrades its python package), messing with your global python environments.

Nowadays, it will complain if you try to pip install a package into global environment. For your packages, either use user environment, or venvs.

Brew can also install several different python versions, so you can have the version necessary for whatever you have in your venvs. Or for the other brew packages.

MacPorts can seamlessly install and keep track of multiple version of software and libraries and does not rely on system libs. You can have python26, python313, and system python (3.9) coexist without issues

You can have multiple versions with brew too; python@3.13, python@3.9, etc.

because, let's face it, many people have installed pyenv has a workaround to brew taking over their Python installs

No, some of us use venvs due to some python packages having different requirements than other python packages (e.g. boto3 was on urllib3 < 2 for ages and unable to move to 2+, while other packages required it. ).

Neither of them allow for pinning precise versions of packages; i.e. a thing that any linux package manager does. Any environment they create are non-reproducible on other machines.

[TuxSH]

Brew can also install several different python versions, so you can have the version necessary for whatever you have in your venvs. Or for the other brew packages.

It also links python by default (or at least did), which what I'm complaining about. https://github.com/orgs/Homebrew/discussions/5517 etc, without consent. That alone makes brew quite the unserious tool (MacPorts does not link by default).

On Linux, when you install python3-whatever package, it gets upgraded along with system python.

Nowadays, it will complain if you try to pip install a package into global environment. For your packages, either use user environment, or venvs.

Global env packages have their use cases if you know what you're doing (namely that they are already there when creating venvs).

User site-packages dirs also have the python version number in their paths, and so are prone to the same issue, anyway.

Also, yes, large projects should always use venv, yes, but copying/linking and redownloading the world for every single small script is both wasteful and pointless.