Table of Contents

  1. Why Nix?
  2. My Requirements
  3. My Workflow
    1. brew install becomes …
    2. brew upgrade becomes …
    3. brew remove becomes …
    4. If-blocks
  4. How it Ends
  5. What’s Next?

Why Nix?

For the past few months, I’ve been using Nix (the package manager, not the OS) as my package manager across multiple devices (MacBooks, Raspberry Pi, Linux workstations). My goals don’t align with Nix’s visions perfectly, but compared to Homebrew (and Apt), it does offer quite a few advantages:

Configure once, run anywhere: Homebrew’s support for Linux is very basic and flaky, and doesn’t work for Raspberry Pi. Nix works across all my systems, macOS (both Intel and Apple Silicon), ARM64 (Raspberry Pi), and x86 Linux workstations.

Declarative package management: I can check in my Nix configurations in a Git repo sync’ed across multiple devices, and apply them in a single command. This also means that removing packages is much cleaner as you don’t need to worry about unneeded dependencies (like apt autoremove or brew rmtree)1.

Supports Python packages: I can declare (python3.withPackages (ps: with ps; [ ipython pip pyyaml requests strictyaml plotly pandas packaging dash scipy ])) which saves a lot of trouble maintaining Python environments.

A large package registry: Once I spent hours trying to build autotrace on my Raspberry Pi, finding out it is as simple as nix-env -i autotrace was an instant-switch for me. You can find most (if not all) packages you need on Nix Search.

My Requirements

I need:

  1. Single file: A single declarative config file that I can check into my version control monorepo, alongside all my other configuration files like Neovim and Hammerspoon’s init.lua
  2. Run everywhere: It should work for all my OS and devices
  3. No boilerplate: It should have as little boilerplate as possible: managing packages can’t be that complicated, right?
  4. One command to apply: I should be able to apply the said config file with a single command with no human intervention (i.e. git pull && apply-nix-env should do it)

(Note: Notice how being “reproducible” is not one of them, despite being one of Nix’s major selling points. This is because personally I’ve never ran into reproducibility issues, at least with Homebrew.)

My Workflow

Due to my specific requirements, my Nix workflow might not align with Nix’s visions either (if there exists such a vision). 2 and 3 ruled out nix-darwin, and I did the simplest setup possible (thanks to Stephen Checkoway):

First have a env.nix file like this:

{ pkgs ? import
    (fetchTarball {
      url = "https://github.com/NixOS/nixpkgs/archive/51ae8856ae59d3724c6c83e81c2854451ca7732d.tar.gz";
    })
}:
with pkgs; [
  (python3.withPackages (ps: with ps; [ ipython pip pyyaml requests strictyaml plotly pandas packaging dash scipy ]))
  btop
  cmake
  ...
]

Apply it with nix-env -irf env.nix, and that’s it.

It satisfies all the requirements above, and to demonstrate the workflow I’ll speak brew for a moment here:

brew install becomes …

  1. Instead of looking it up on Homebrew Formulae, find it on Nix Search
  2. Edit env.nix and add the new package
  3. nix-env -irf

brew upgrade becomes …

  1. Just update the hash in your env.nix (which I later automated with a script), and
  2. nix-env -irf

brew remove becomes …

(or maybe you want brew rmtree)

  1. Remove that entry from env.nix, and
  2. nix-env -irf

(This is a much better user experience than brew, even with rmtree.)

All of these operations are much faster than Homebrew (IF all binaries are available).

If-blocks

When you need it across multiple OS, or when you need some packages conditionally only on some machines, you can use lib.optional to add if-blocks, like this:

with pkgs; [
    btop
    ...
    zsh
] ++ /* macOS */ lib.optional pkgs.stdenv.isDarwin [
  blueutil
  coreutils # shadows macOS commands like date, basename
  diffutils # shadows macOS's BSD diff
  duti
  gnugrep # shadows macOS's BSD grep
  gnused # shadows macOS's BSD sed
] ++ /* Linux */ lib.optional pkgs.stdenv.isLinux [
  nethogs
  trashy
] ++ ...

You can also add conditions on other info, e.g. lib.optional (builtins.getEnv "USER" == "hexacera").

How it Ends

That does satisfy all my requirements, migrating and provisioning new machines are now easier than ever, but why is this titled “(A Failed Attempt)”?

Documentation: Let’s just say that, for me, ChatGPT is Nix’s best (or should I say only) documentation. Whenever your use case deviates a little from norm, you’ll be in a hell of sprawling cryptic forum posts and trying random stuff until it works. And indeed my workflow is somewhat niche so these things happen regularly. There’s always a better use of my time than fighting with my package manager.

Freshness: I want the latest svt-av1 as each release comes with significant improvements, I don’t want to miss out on them but I’m lazy enough to not want to build from master. With Nix (nixpkgs), the version bump PRs usually comes quickly (or writing one is actually pretty easy), but it usually takes weeks for the PRs to be reviewed and merged. When PRs eventually get merged into staging, it takes another month for them to make it to unstable. Homebrew’s svt-av1 bottle is already 3.0.0 as of now (2025-03-08), and I’m still waiting on nixpkgs’s 3.0.0 bump to be merged.

Binary availability: With brew upgrade or apt full-upgrade, you know exactly what will happen: you’ll be downloading binaries and that’s it. With nix-env -irf, once in a while I’ll find my Raspberry Pi at 100% CPU because it is trying to build Zig for some reasons. I had to script nix-env -irf, making it do a dry-run first just to make sure it will not attempt to build the universe from source today.

Eventually I found myself migrating packages back from Nix to Homebrew.

What’s Next?

My attempt to replace Homebrew with Nix failed, but Nix is still great (even for someone that doesn’t care about reproducibility), and I still hope (and believe) Nix will get better over time, with the chicken-and-egg problems of easier onboarding → more adoption → better documentation/debuggability → easier onboarding … I’ll continue to contribute when I have the chance.

Also, let me know if you are also interested in using Nix on macOS, I have wasted so many hours making it work, and might be able to save some of yours :)

  1. Though later I discovered brew bundle and Brewfile which offers more or less the same benefit. ↩