Ask HN: Best Alternative to Homebrew in 2021?

Homebrew project leader here: I hope you&#x27;re able to find a package manager that better fits your needs and I&#x27;m sorry that Homebrew is not currently doing so.<p>---<p>Homebrew upgrades dependencies and dependents of those dependencies (which, admittedly, can feel like unrelated) on installation and upgrade. As mentioned in other comments, you can customise this behaviour with `HOMEBREW_NO_INSTALL_UPGRADE` or `HOMEBREW_NO_AUTO_UPDATE`.<p>Homebrew does this because the alternative is sometimes breaking things. An example:<p>- you want to install `virtualenv` that depends on `python@3.10`<p>- the binary package for `virtualenv` you want requires the newest `python@3.10`<p>- this upgrades `python@3.10` on installation<p>Now, Homebrew has a choice. Either we upgrade _everything_ that depends on `python@3.10` that you have installed or we knowingly break some of the things you have installed that depend on `python@3.10`. We choose the safer option by default.<p>The more time left between updating&#x2F;upgrading, the more likely to have more dependencies updated which requires more dependents to be updated.<p>---<p>Regardless, I appreciate this is a problem and we&#x27;re still figuring out potential solutions for this problem. A reminder that we&#x27;re a volunteer run project so it&#x27;s not always as easy as we&#x27;d like it to be to get these changes out quickly.

I just reached the same breaking point -- and normally I am pretty sympathetic to software jank, but the maintainer of homebrew is so actively hostile and rude that my degree of empathy is significantly less -- and switched to Nix, which is quite good, conditional on three gotchas:<p>1. Nix has very limited support for GUI applications of the kind that you&#x27;d find in `brew cask`. Not no support, some of them are there, but limited support compared to brew. If you use brew as an out-of-the-box install-everything setup like me, you&#x27;ll not be able to replicate that easily with Nix.<p>2. Nix can&#x27;t currently build Swift applications because of some Xcode something I didn&#x27;t fully understand.<p>3. I found a small number of packages that are broken on Nix on my aarch64 &#x2F; M1 MacBook Air (and marked broken, so when you try to install it complains) and a small number that are broken without being marked broken. In specific, I think R was one that surprised me -- this is a major programming language and although the build requirements are onerous (it&#x27;s a mix of C and Fortran), I would think it would work.<p>That being said the actual process of installing, updating, and upgrading seems much faster and dramatically less shitty than homebrew, and so I recommend migrating stuff off of brew anyway.

Brew&#x27;s package selection is unmatched and it works great <i>for a particular purpose</i>. Keep using it, but stop using your dev machine&#x27;s system package manager to manage project dependencies. There are a bunch of good reasons not to do that, anyway. For server stuff, probably use Docker. Brew is for your tools you personally use, that you mostly want to be at latest. If a project needs, say, a compiler and library at a specific version, <i>define that in the project</i> and use something that will manage that for you, which will typically be language-specific—damn near every language has an &quot;Xvm&quot; now, where X is the first letter of the language or platform, or else something equivalent, right? That&#x27;s not to cater to Mac with Brew, it&#x27;s because that&#x27;s <i>a very good idea</i> on any platform.<p>You shouldn&#x27;t use the system package manager on Ubuntu or Red Hat or whatever the way you&#x27;re using Brew, either, unless you&#x27;re exactly matched to your deployment target—same distro, same version, and you don&#x27;t upgrade locally unless the servers are getting upgraded—and are scripting your local package installations and upgrades with the same script you use to deploy on the server.

I&#x27;ve personally had very good experiences switching back from Homebrew to MacPorts. Wouldn&#x27;t go back to Homebrew.<p>I find it much faster now, which is quite funny to me because back when Homebrew was new (and a lot less opinionated) it was much faster than MacPorts, especially with the bottles (binary packages) feature.<p>Today, MacPorts has binary packages, doesn&#x27;t randomly force incredibly slow updates when I just want to quickly install something or run a package search, has entirely opt-in telemetry through installing a package (mpstats) and still lets me customise packages (through the variants system, which is more powerful than the with --with-feature system Homebrew seems to have abandoned).<p>The only pain point I&#x27;ve found is upgrading to new macOS releases, though I&#x27;ve often found just reinstalling MacPorts itself will get me going again in a pinch without having to take inventory of my installed ports and reinstall everything from scratch.

I think, you don&#x27;t need to choose any other package manager because homebrew is the most mature thing on macos. Just disable autoupdate when installing something: HOMEBREW_NO_AUTO_UPDATE=1 brew install &lt;formula&gt;

I switched to Macports back in my Mac days, used it as my daily driver for about 18 months before moving to Linux.<p>Macports has this appearance of being &#x27;dated&#x27;, and not the cool kid compared to Homebrew. But it doesn&#x27;t have an opinion on what version of software you can install. Want postgres 9.4? Go ahead and install it. Want some ancient version of some other library? That&#x27;s fine.<p>Dealing with custom port files and repositories isn&#x27;t quite as easy, I suppose, but that&#x27;s not really much different to setting up a debian repo in that it&#x27;s a use case you won&#x27;t encounter nearly as often as just installing stuff.<p>I also used nixpkgs at one point, many moons ago. That was also nice but not the most practical on a Macbook with 128GB storage, when you also have Docker, npm&#x2F;ruby dependencies, and your native Mac software in the mix.

It’s a strategy. Package managers have to choose a strategy: slow, crusty and stable or bleeding edge? It’s not CentOS… it’s a local dev machine. The same scenario will occur on Arch Linux.<p>Fortunately Homebrew has lots of helper scripts to upgrade DB’s like Postgres. You probably saw some scroll back with a command to upgrade from 12 to 13 or 13-14 etc. It will even download and install an old version in order to upgrade safely.<p>I understand the frustration but what is the alternative? Pinning every dependency? The reason so many of your packages were updated was likely because a core dependency was upgraded like OpenSSL.

nix.<p>It&#x27;s confusing, but we&#x27;ll get there. You&#x27;ll need&#x2F;want:<p>- nix, the tool&#x2F;build system.<p>- nixpkgs, the world&#x27;s most up-to-date and underfunded package repository.<p>- nix-darwin, bringing a NixOS experience to Darwin. Not perfect, but pretty damn great.<p>And optionally,<p>- home-manager, a nix-based opinionated tool to manage dotfiles and other stuff in your home directory.<p>And finally, some things to avoid and experimental features to use:<p>- do not ever use `nix env -i` to install things ala homebrew, apt, etc. This is a trap. You don&#x27;t want this.<p>- use nix flakes. Sure, it&#x27;s experimental, but it&#x27;s what you _do_ want. Reproducible, version-pinned builds.<p>- if you use direnv, or are familiar with it, check out nix-direnv, which is like direnv on crack. Instead of managing your packages globally, manage them per workspace or project.

A lot of the usual &quot;it&#x27;s bad&quot; &quot;it&#x27;s not bad for me&quot; discourse in these threads. Could people raise the bar a bit and talk about specific problems they have had with homebrew - other than the auto-update, which we&#x27;ve already noted can be changed by setting HOMEBREW_NO_AUTO_UPDATE=1? Thanks.

You can disable autoupdate by setting HOMEBREW_NO_AUTO_UPDATE env<p><a href="https:&#x2F;&#x2F;github.com&#x2F;Homebrew&#x2F;brew&#x2F;blob&#x2F;7d31a70373edae4d8e78d91a4cbc05324bebc3ba&#x2F;Library&#x2F;Homebrew&#x2F;manpages&#x2F;brew.1.md.erb#L202" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Homebrew&#x2F;brew&#x2F;blob&#x2F;7d31a70373edae4d8e78d9...</a>

In the past i used brew to install EVERYTHING, this lead to situations like in OP of DBs, compilers, interpreters and other things that i wished stay frozen to get updated by surprise<p>Since then i moved to manage everything that needs to stay frozen by either a versioned formula&#x2F;cask (python@3.9 and so on) or use brew to install a version manager (asdf,pyenv,pipx) and then use that. Results are much better once I did that<p>Although versioned casks&#x2F;formula exists you will still get minor versions - python@3.9 will update from 3.9.0 to 3.9.1 is that ever exists. so while completely protecting you from upgrades it does minimize the the risk<p>Also, there is really no need to install virtualenv directly from brew. A very bad practice. Of course doesn&#x27;t change the fact that brew did things that are unrelated to what you asked of it

I started using nix. It’s difficult and search results are not often helpful.

One vote in favor of macports here. I first went from homebrew to nix. Nix was fine, the concept is great but I found the language to be difficult. Ports is closer to homebrew in its simplicity, and has a big catalog (including much of the scientific stack that was removed from homebrew).

MacPorts and Nix are fine to use alongside each other.<p>I recommend using Nix alongside a couple other systems so you have escape hatches.<p><pre><code> - Nix - pkgsrc or MacPorts ‘just in case’ they&#x27;re more convenient for some package for any reason - Homebrew, exclusively to use for Casks (which are really a separate system from the rest of Homebrew) </code></pre> To get the most out of Nix, you&#x27;ll need to take some time to really learn it. For managing services like postgres, it&#x27;s nicest to use Nix-Darwin (a module system for managing services and programs, including automatic startup via LaunchD) but if you want to always keep the same Postgres with Nix-Darwin, you&#x27;ll have to learn how to pin packages.<p>If you use Nix with Flakes, it&#x27;ll feel a lot faster (much faster than Homebrew). If you use old-school Nix, it&#x27;ll be slow if you call some deprecated commands.

I cannot remember why, but I chose pkgsrc (<a href="https:&#x2F;&#x2F;pkgsrc.joyent.com&#x2F;install-on-osx&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pkgsrc.joyent.com&#x2F;install-on-osx&#x2F;</a>). It is however of varying quality.

I built a feature in arkade [1] to pull in binaries for CLIs for infrastructure and developer tooling that I wanted to use - it now has 72 CLIs that you can pull down with a single command and most importantly, as near to instantly as you&#x27;re going to get.<p>For instance: arkade get kubectl@v1.22.1 yq helm faas-cli<p>It&#x27;s not got anywhere near the catalog of brew, and doesn&#x27;t compile software, or help you find lib-xyz for your Yubikey, but it is really fast and has a growing community behind it.<p>It works on MacOS, Linux, Windows and arm hosts to determine the correct download URL and pull in a binary.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;alexellis&#x2F;arkade" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;alexellis&#x2F;arkade</a><p>Contributions are welcome.

I&#x27;ve been using MacPorts for over a decade now, and I&#x27;m very happy with it. I certainly much prefer its default choice of install prefixes (&#x2F;usr&#x2F;local should be reserved for things I install <i>manually</i>; &#x2F;opt&#x2F;local doesn&#x27;t clash with anything else I&#x27;m aware of).

After years of dealing with it I just run most of the software from docker containers and use homebrew for random cli tools.

The fact that homebrew is awful is one of the huge reasons I don’t use MacOS for development like all my co-workers. Instead I use Windows with WSL because the company won’t allow me a Linux laptop.<p>If I had to use a Mac my solutions would be to alway use Docker, a virtual machine, or a remote dev environment of some kind.

When I first started using Macs 5 years ago, I explored both macports and homebrew. As soon as I saw how homebrew screwed around with root, and how it installed itself in &#x2F;usr&#x2F;local and required strange machinations I looked more at Macports.<p>Ports have a long history from the <i>BSD Unices and Macports keeps that ethos. It installs neatly in &#x2F;opt and doesn&#x27;t screw around with MacOS except in the approved ways (eg for Java and Python frameworks).<p>I still use Macports and it&#x27;s had everything I&#x27;ve needed and when I hit bugs during the Big Sur beta, they were fixed quickly and directly, while still complying with Apple&#x27;s beta policies.<p>I&#x27;ve dabbled with Nix, but it&#x27;s a bit </i>too* prescriptive for me.

Came here hoping to see some recommendations on getting started with nix on MacOS, or maybe a favorite blog post or series.<p>I&#x27;ve tried the nix.dev installation + nix-darwin instructions 4 or 5 times but never make it very far.<p>Seems like I should generally prefer a multi-user install? Does nix-darwin play well with that?<p>As I supposed to `sudo -i nix-channel --add &#x2F; update` or not use sudo? Is unstable the generally recommended channel? Do I use sudo with nix-darwin, since it&#x27;s supposed to be kind of like NixOS &#x2F; system-wide?<p>And then I usually give up, count my blessings for homebrew, and resolve to never again waste another 2 days trying to figure out nix.<p>Rinse and repeat in 1 month.

Before I used homebrew, I was a MacPorts user and that was a terrible experience for me.<p>Been running with homebrew for at least a decade since, and I cannot recall any negative encounter other than the hassle of grabbing xcode command line tools when I upgrade a major version of Mac OS, which is a minor detail.<p>I get the appeal of MacPorts &amp; a dedicated separate package path but it caused all sorts of problems for me v. the integrated approach of homebrew.<p>O there was another negative now I remember -- had to uninstall brew version of MacVim &amp; install manually. But that not a big issue either &amp; typically, all of the brew packages are CLI only for me.

A while ago there was a post on HN about <i>pkgsrc</i>[1][2][3], which works on Mac, among other platforms. I haven&#x27;t tried it, but it may be worth a shot.<p>[1]: &lt;<a href="https:&#x2F;&#x2F;rubenerd.com&#x2F;using-netbsds-pkgsrc-everywhere-i-can&#x2F;" rel="nofollow">https:&#x2F;&#x2F;rubenerd.com&#x2F;using-netbsds-pkgsrc-everywhere-i-can&#x2F;</a>&gt;<p>[2]: &lt;<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27293108" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27293108</a>&gt;<p>[3]: &lt;<a href="http:&#x2F;&#x2F;www.pkgsrc.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.pkgsrc.org&#x2F;</a>&gt;

I gave up on brew and other package systems like it a long time ago. I found it far, far easier to install Ubuntu 20.04 and use that as a utility machine.<p>Even on a system like that, many times when I interact with package managers like conda, it ends up compiling some huge package from scratch. I consider that a failure.

I very much dislike that autoupdate is the default. This is user-hostile.<p>I instructed you, brew to install something. Not to spend an eternity autoupdating things.

I switched to MacPorts and never looked back, about two years ago. So far a much better experience than Homebrew.

I&#x27;m surprised people still use postgresql from homebrew. Like honestly, I use brew for any CLI command only like zsh and git. Well maybe some programming language as well but I would never, ever install database with it unless I&#x27;m desperate. Anything that can be dockerized, just use docker.

I never understand these complaints about homebrew. Of course, that&#x27;s because I set<p><pre><code> export HOMEBREW_NO_AUTO_UPDATE=1 </code></pre> in my zshnev so long ago that I forgot about it, and just enjoyed a great product from a great community.<p>Is it a bad default? Sure, probably, spooky-action-at-a-distance is not great. But it&#x27;s just a default, if you don&#x27;t like it, change it, one line of shell config is simpler switching distros.

There are some tips which others might already have alluded to:<p>1. Python has built in virtual environment support. python -m venv should do the trick. 2. Use docker for running Postgres, MySQL etc with some directory mounted for data.

nix has a very steep learning curve, but I have been using it on macOS for a while now. Can’t recommend it enough. Even started using it on my personal PC, which allows me to use the same nix flake on both systems.<p>EDIT: Personal PC is running NixOS not Windows.

I didn’t think brew <i>upgrade</i>d packages automatically? Just <i>update</i>d the index? Am I missing something here?

I have moved to Nix on two of my three machines – the two laptops have Archlinux32 and MacOS Mojave. I should replace Homebrew installed packages with Nix packages on my desktop iMac too, but in the mean time I have used Macports and some Nix packages for installing new packages.

I have reasonable experience with macport, just remember to enable multithreading, or it can be exraordinarily slow.

I&#x27;m moving to nix. I use a combination of macports and brew, and brew&#x27;s current behavior is unusable for me, so it&#x27;s going to be relegated to &quot;use brew for package X until I find an alternate solution for package X&quot;.<p>I don&#x27;t want to have to keep updating brew just to keep from having to wait ever-increasing amounts of time when I want to install a new package or upgrade a specific one. I never have these issues with macports, and won&#x27;t have them with nix.

My current solutions mainly relies on homebrew + Macports + conda.<p>Macports primarily for system level dep. use this whenever packages available.<p>Fall back to homebrew when not available on Macports. This includes brew cask which is unique.<p>This dual setup may requires you to carefully separating the 2 when installing and updating. I do this by installing brew in custom location (not &#x2F;use&#x2F;local) which is now the default on ARM. Also some shell functions that selectively control the environment (essentially I use an environment that only sees port to update port, vice versa.)<p>Lastly, conda for dev environments, mostly for Python stack. But it is also useful for other stuffs (conda is a cross platform package manager and in this sense it is similar to brew which also support Linux.) Obviously selections is not as broad comparing to brew.<p>On computing facilities, I used to use linuxbrew to install some “system” dependencies that’s missing, including zsh, mosh, tmux, tree, etc. But obviously I cannot install in the recommended path by brew, which means compiles from source. And it is not robust (and they also say this is not a supported pattern.) I now use conda for this and is very robust (conda uses a hack to install precompiled binaries to arbitrary prefix.)

Macports

You&#x27;re doing it wrong.<p>Use Homebrew only for tools and not for critical services like databases and use a cloud server or local virtualization like VMware Fusion (which is free these days for personal use) to run services because major distro packages have far more eyes to check for stability issues.<p>I never understand people trying to run every parts of the development environment through a local machine&#x27;s third party package managers which would forbid anyone else being able to check your work right then as you&#x27;re only running it as localhost, not to mention the power can be down at any moment you&#x27;re not using your machine and you can&#x27;t even switch machine yourself to work from easily.<p>And then when deploying, you&#x27;ll be running it on Linux anyway which would likely bring little consistency issues.<p>Do yourself a favor, either spend $5&#x2F;mo for a cloud Linux and run your stuff remotely or run a locally virtualized Linux and stop using third party package managers no one is using to run on production.<p>And you can happily keep Homebrew and also install Homebrew on Linux to have unified tool sets on your Mac and Linux CLI tools.

My experience with MacPorts has been generally good, apart from dealing with OS upgrades which are more painful than necessary, but I&#x27;ve honestly never tried Homebrew so I can&#x27;t compare them directly.<p>Personally, I find that the whole Homebrew &quot;theme&quot; where every command&#x2F;thing is named after something alcohol&#x2F;brewing-related (cask, bottle, formulae, tap, keg, etc) is a huge turnoff.

I use brew for system cli tools (eg wget, ffmpeg) and Docker when I need a consistent environment (eg to match what I run in production)

I&#x27;m surprised I&#x27;ve not seen Spack mentioned here. Spack especially is great for home installs. It&#x27;s aimed mostly at HPC cluster users, who by default need multiple versions of compiler toolchains, programming languages, libraries, but works well on Mac too.<p>I hate it, but Anaconda might work too, so long as it&#x27;s not a corporate laptop where you need a license.

sorry OP by this is a clickbait rant from someone who just did not made his homework and ended loosing time and data.<p>- Homebrew is rolling - always was and never claimed otherwise.<p>- OTOH for key packages (say databases) it has available versioned bottles. for postgresql one have:<p><pre><code> - postgresql@10 - postgresql@12 - postgresql@9.4 - postgresql@9.6 - postgresql (points to latest) - postgresql@11 - postgresql@13 - postgresql@9.5 </code></pre> - Finally, no one is forced to update everything at all. run `brew outdated` and pick whatever you want updated then `brew update foo`...<p>In short, none of what happened to the OP is due to inherent flaws in homebrew... QED.

I would suggest to not use brew for anything that depends on python, ruby etc. Most of the time you can use e.g. asdf to manage all your dev dependencies. Also, most softwares allow you to install them without hombrew. (e. g. <a href="https:&#x2F;&#x2F;postgresapp.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;postgresapp.com&#x2F;</a> for postgres). I have seen so many installations screwed up because hombrew upgraded some packages without requiring a confirmation from the user. It&#x27;s a bit unfortunate given that so many packages are on hombrew.

Have a look at pkgsrc - <a href="https:&#x2F;&#x2F;www.pkgsrc.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.pkgsrc.org&#x2F;</a><p>It is my first choice since a while and if it&#x27;s not there I go to homebrew

Maybe [1] <a href="https:&#x2F;&#x2F;pkgsrc.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pkgsrc.org&#x2F;</a> ?<p>Check [2] <a href="https:&#x2F;&#x2F;pkgsrc.se&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pkgsrc.se&#x2F;</a> before, to see if the availability and the &#x27;freshness&#x27; of packages fits your needs.<p>edit:<p>[3] <a href="http:&#x2F;&#x2F;pkgsrc.joyent.com&#x2F;install-on-osx&#x2F;" rel="nofollow">http:&#x2F;&#x2F;pkgsrc.joyent.com&#x2F;install-on-osx&#x2F;</a> if you don&#x27;t want to compile and have binaries instead.

For databases specifically, I like a little tool called DBngin. It&#x27;s perfect on MacOS for installing various versions of databases. I used to install MySQL 5.7 for an older legacy application because I was finding it challenging to juggle different versions on MySQL w&#x2F; Homebrew. I know it handles MySQL, PostgreSQL, and Redis. Maybe is handles other stuff, but I haven&#x27;t checked.<p><a href="https:&#x2F;&#x2F;dbngin.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dbngin.com&#x2F;</a>

Brew unrelated but especially for PostgreSQL on a mac I can highly recommend <a href="https:&#x2F;&#x2F;postgresapp.com" rel="nofollow">https:&#x2F;&#x2F;postgresapp.com</a>

I have tried macports, spack and to a limited extent homebrew. But the package manager that seems to work best for me is actually Anaconda, which is very surprising.

Nowadays virtualenv is built into Python and you rarely need to install it.<p>Try:<p>python -m venv

Homebrew is a great system for most situations. Great effort by an amazing group of volunteers.<p>To fix the very real issue you describe, I would like to see a --isolate option for mission critical packages. All the dependencies would be contained in a separate, package specific directory within &#x2F;opt or &#x2F;local. The rest of the dependency management could happen without affecting the isolated package.

I am Python dev and I never heard of someone using brew to install virtualenv before. I think that you are using brew for the wrong purposes, I suggest the following instead:<p>- Python already includes the venv module, you don&#x27;t need to install anything, just run `python -m venv &lt;venv_dir&gt;`<p>- You should manage multiple versions with pyenv instead of brew. Pyenv can be installed with brew.

Conan can be made to do what homebrew does with minimal effort, I have written some convenience wrappers around it which makes it slightly easier to use for this use case, you can have a look here: <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;aucampia&#x2F;proj&#x2F;xonan" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;aucampia&#x2F;proj&#x2F;xonan</a>

I&#x27;ve found that `brew pin` is becoming a necessity for things not breaking on my machines. after Postgres breakage that cost me a half day of work, and fish breakage that cost me a bunch of personal time, I try to pin things that have the high probability of breaking due to an update.<p>not optimal, but sadly necessary.

Asdf is the bees knees for dev tools.<p><a href="https:&#x2F;&#x2F;asdf-vm.com" rel="nofollow">https:&#x2F;&#x2F;asdf-vm.com</a>

Linux on a normal laptop or computer.

Why not check FreeBSD?<p>Here are some arguments why it may be worth it this time :)<p><a href="https:&#x2F;&#x2F;vermaden.wordpress.com&#x2F;2020&#x2F;09&#x2F;07&#x2F;quare-freebsd&#x2F;" rel="nofollow">https:&#x2F;&#x2F;vermaden.wordpress.com&#x2F;2020&#x2F;09&#x2F;07&#x2F;quare-freebsd&#x2F;</a>

The same thing happened to me when I upgraded vim ! I thought why the heck would postgres requires an upgrade if I was upgrading vim&#x27;s minor version ! It took ages...<p>EDIT: for me this is a minor issue. i&#x27;ll continue using `brew` as it does the job quite well

100% unrelated but I would suggest installing `pipx` when you need python packages to use from the CLI&#x2F;outside a python project environment. `pipx` installs each package in its own virtualenv, so it is independent of your system python.

It is really simple to compile Postgres from source and it only takes a few minutes. You can have multiple versions running on a single machine and installed in your preferred directory.<p>If you forget to include the extensions, you can add them all later.

I’ve used pkgin[1] on my Mac. It works fairly well, and I appreciated how quick the installs were.<p>[1] <a href="https:&#x2F;&#x2F;pkgsrc.joyent.com&#x2F;install-on-osx&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pkgsrc.joyent.com&#x2F;install-on-osx&#x2F;</a>

Given that macOS is a BSD variant, and given Apple&#x27;s billions, it&#x27;s a bit disappointing that Apple doesn&#x27;t directly support (both engineering wise and financially) a BSD package manager.

I avoid it at all costs. Sometimes it takes more time to figure out how to install something because guides are quick to recommend brew, but there&#x27;s usually an alternative

I could not get Postgres installed through NixDarwin, so I installed with Postgres.app for MacOS. With it you can easily manage Postgres versions.

Really you should switch to debian if you want stable packages. It&#x27;s not for the latest hotness but it achieves the stability it advertises.

You may have already tried it, but you can run `brew postgresql-upgrade-database` after postgres is upgraded to fix your local databases.

Just disable the auto-updates.<p>Also, I&#x27;m 100% certain all it did was update the formulae (similar to apt-get update, NOT apt-get upgrade).<p>I&#x27;ve been using homebrew for years and this is the default behavior, so unless you purposefully set it up to <i>upgrade</i> everything this is PEBKAC.<p>AFAIK the only time it <i>upgrades</i> everything is when you do a blanket `brew upgrade`. And if you&#x27;re pinned to something like postgresql@10 it will stay at that major version.

Why did you want to `brew install virtualenv`? That’s no longer the current way to work with python. Virtual environments are now in the standard library:<p><pre><code> python -m venv &#x2F;my&#x2F;directory </code></pre> I’ve never had any problem with homebrew in over a decade’s usage. But yes, don’t use it for python development tooling: use pyenv and python -m venv and pip for that.

IMO packages like virtualenv should be brought in by a local python that&#x27;s installed, not brew.

This si literally why docker exists. I would never install something on a system and then complain it is being updated from time to time. The system needs to stay safe and follow a path of updates in order to cover vulnerabilities and such. Put it in docker and version lock it.

Why are you using virtualenv instead of `python3 -m venv`?<p>Just wondering.

Macports has served me well for the last 18 years.

None, I just use the UNIX experience provided by macOS.

Why Ruby tho?

pacman

You can install Gentoo in a prefix on OSX. I used to do that.

User error. You should have known about pinning versions. If this is the reason you want to change package managers, you should consider this. Either that or maybe macOS isn&#x27;t the OS for you. Try gentoo.

If you want package managers, go Linux.

If your only problem is you don&#x27;t like it surprise-updating everything, maybe you should set up an automated patching schedule.

My experience is that both (Macports, Homebrew) are comically unreliable and frustrating to use. That said, with my insistence to install under $HOME, Macports seems to work slightly better. But truly, I got the best results from downloading and compiling every single flipping dependency myself.