A useful way to frame this isn’t “is it worth tens of hours to avoid a future reinstall” but “where do I want my entropy to live”. You’re going to invest time somewhere: either in a slowly-accumulating pile of invisible state (brew, manual configs, random installers) or in a config that you can diff, review and roll back. The former feels free until you hit some cursed PATH/SSL/toolchain issue at 11pm and realize you’ve been paying that tax all along, just in tiny, forgotten increments.
I think where Nix shines isn’t “one laptop every 6 years” but when your environment needs to be shared or recreated: multiple machines, a team, or a project with nasty native deps. At that point, nix-darwin + dev shells becomes infrastructure, not a hobby. You don’t have to go all-in on “my whole Mac is Nix” either: keep GUI apps and casual tools imperative, and treat Nix as the source of truth for the stuff that actually blocks you from doing work. That hybrid model matches what the article hints at and tends to give you most of the upside without turning your personal laptop into a second job.
One of the biggest annoyances I have with doing this with Nix vs another tool is that Nix doesn't natively communicate back state changes so that you can make them reproducible.
If I make a git repo, place '~/.config/newsapp.conf' in there and then symlink it back to '~/.config/', if NewsApp introduces a new variable in its settings I am immediately aware because Git will complain about being dirty. However, Nix will happily just nuke that .conf and rebuild whatever is in your configuration, without letting you know about state. Which is ultimately bad for reproducibility. It's a huge blind spot in Nix.
I tried getting Nix working a couple of months ago and ditched it because changing some Tower settings updates the global gitconfig (as it should in this circumstance) and Nix would wipe them out.
All of it seemed way too annoying compared to just having a dotfiles repo, and if it couldn’t handle the Tower/gitconfig issue I know for sure everything else I was going to run into wasn’t worth it.
For what it's worth, you can put a git repo inside a nix configuration / flake folder and it will tell you the repo is dirty. 'nh' also has commands to tell you about state. But it shouldn't require outside tools.
The way I do it is have config files in my Nix config folder, then use Nix to symlink them and I use git to make me aware of state changes, that I might want to make reproducible. But that's just me being used to my old git ways, using 'nh' gives much more clarity.
The "true" Nix way is putting the entire contents of whatever config file in a .nix file, then erasing the original config and have Nix recreate the config (preferably read-only) in place. You become truly reproducible but for obvious reasons applications get mad when you make their config file read only.
This really hinges on whether you let state accumulate, and where you let it do so. NixOS generally creates a dedicated user and data directory for its services, for example. I make some of my XDG config directories symlinks to the nix store because I want those configurations to be read-only. home-manager should ask before making modifications outside of the nix store (or make a backup).
This is not only a Nix problem, fwiw. I first encountered this with, say, running ZNC in Docker. It will happily write logs and configs to a temporary directory in the container and get blown away on restart unless you mount persistent volumes in just the right spots. Syncthing can be configured to manage its own config or it can be configured fully by Nix, etc.
It sounds like you're talking about home-manager, which is a third-party Nix module, not Nix itself. I've been using Nix happily for several years now for work and personal without needing to use home-manager at all (since I don't like it either).
It was just an example. Other packages could also set new variables / parameters in their configuration. It might not be a problem in the beginning if the variable is just repopulated, but it might blow up in your face in the future.
If you use Nix you're completely blind to that unless you A) religiously check your state or B) use another tool like 'git' or 'nh'. Like I said, it's a blind spot, both figuratively and literally.
This problem may be specific to Darwin because on NixOS I've never had a file overwritten by nix (even with home manager). When a file is managed by nix it's a symlink to a read-only filesystem (/nix/store), so no program can overwrite it. If the symlink is replaced by a regular file, nix refuses to reapply.
Correct for data, not for config files. Config files are stateful unless you do the procedure I mentioned, because they're generated at first application launch.
If you try to symlink into an existing file Nix will indeed complain, which is why you have to erase the config file and then put yours in place. You can either write it out from a .nix file (pure reproducibility) or from symlink copy from a file managed by git (technically impure but effectively reproducible).
But my config files (/etc, ~/.config, etc.) are either managed by nix (and no program can modify them), or they are not and in that case nix will never touch them. In what situation would nix overwrite a file?
Actually Nix even errors out if the file it tries to write is already in place. I have this sometimes when I move fish functions from being defined adhoc with funcsave to putting them in my nix config because I want them on all my machines.
>I think where Nix shines isn’t “one laptop every 6 years” but when your environment needs to be shared or recreated: multiple machines, a team, or a project with nasty native deps.
I'd like to add the third thing, which is just iteration. It's very tricky to maintain advanced workflows even locally. I'd guess many won't even try to compose things that could work in combination (often self-hosted services), when they know they can't reliably maintain those environments.
> keep GUI apps and casual tools imperative, and treat Nix as the source of truth for the stuff that actually blocks you from doing work
I landed somewhere similar for gaming.
When I first got my Legion Go, there were a whole bunch of gaming distros, but none was more popular than the other. I read a bit about immutability, got curious, and installed Jovian-NixOS (which is to NixOS what Bazzite is to Fedora).
I liked that it gave me the Steam Deck experience on unofficial hardware, and it was neat to be able to play with e.g. replacing the desktop shell. However, a keyboard-centric configuration scheme is a bad pairing for a touch-centric device. Little things, like changing the timezone, became needlessly frictionful.
Now I'm on the official SteamOS, with Nix as the package manager. It seems to be a good pairing. Nix lets me install Linux utilities on Steam's otherwise-immutable filesystem. And I can use the Steam UI to change things like the time.
I'll probably write an article in the next few weeks on using Nix to make Linux-native copies of Windows-built games.
I've tried nix-darwin a time or two in the past. Every few years when homebrew makes a "hostile" change and I get upset I consider trying it again (now most recently with changes to gatekeeper). I think I'll get to doing so in the next year or so.
But I think just in fairness, the comparison here for flakes should be to Homebrew bundles. My packages are managed in a bundle: https://github.com/Julian/dotfiles/blob/main/Brewfile and then locked by a lockfile: https://github.com/Julian/dotfiles/blob/main/Brewfile.lock.j... and installing is just `brew bundle install`. All native Homebrew functionality. In practice I have never had an issue with non-reproducible builds across my machines (partly because the tendency on macOS is to run the latest versions of things and stay up to date).
(But again I do find nix-darwin interesting to try for other reasons.)
Very nice, I think I'll be moving my "must-have" homebrew packages to a Brewfile. FYI tho, Homebrew no longer supports Brewfile.lock.json (it was always just a log anyway, not a lockfile). https://github.com/Homebrew/homebrew-bundle/pull/1509
Fun, thanks for letting me know, will remove it :)
(I'll still stick with "I never really have run into a version issue for things I use Homebrew for, for places where it matters, I have whatever-programming-language-lockfile-for-the-project-I-am-developing" for cases where I need to be sure the setup is reproducible, which is why I've clearly never noticed this file was useless).
> the comparison here for flakes should be to Homebrew bundles.
The bundler integration for nix-darwin actually just bakes tightly-controlled Brewfiles. It’s still worthwhile though, since part of the “tightly-controlled” means better cleanup when you remove things.
> The consequence is me, spending a few hours debugging my environment instead of writing code.
But then I also see this:
> I’ve spent a lot of time recently moving my entire workflow into a declarative system using nix.
I can see how this can be beneficial for someone who switches systems very often, reinstalls their OS from scratch very often, or just derives a lot of pleasure/peace of mind knowing that their dev env is immutable.
I change computers once every 6 years or so, maybe more. To me this looks like exchanging a couple (hypothetical) hours of debugging 6 years in the future by tens of (guaranteed) hours trying to climb up the nix learning cliff.
I am happy that it works for the author though, and knowing that it's possible is good in case my particular development circumstances change.
Long-time (by now) Nix user here. It's even worse than a few hours of debugging. In my experience it requires continuous maintenance, options tend to be deprecated and moved around on a regular basis (at least in NixOS and home-manager), things like NeoVim break regularly as a result of friction between the immutable world and a lot of plugins expecting a mutable world, etc. I do install my Mac from scratch every 6 months or so (I like a clean system), but with a dotfiles repo and Homebrew, it takes me about an hour to set everything up again, which is far less time than maintaining a Nix-managed system.
For me Nix/NixOS is by far the most effective for deploying servers, development VMs, etc. I do this regularly, so it pays off - I have a familiar environment completely set up in minutes. Another place it pays off, even on macOS, is for development environments, especially if you have to pull in a lot of native dependencies (which can happen in mixed Python + C++ projects, mixed Rust + C/C++ projects, etc.).
Nix shines in all difficult cases, like setting up complex cross-compilation environments, building for old glibc versions, etc. You set it up once and then it's really easy for yourself and other project contributors to get the same build environment.
Like any tool, a good engineer knows when to apply it.
> I do install my Mac from scratch every 6 months or so (I like a clean system), but with a dotfiles repo and Homebrew, it takes me about an hour to set everything up again, which is far less time than maintaining a Nix-managed system.
Er, YMMV I guess? IMO if you're spending more than an hour fussing with it per 6 months, you're doing something weird
Nix is not worth it if all you want is configuring your home computer. The learning curve is steep and has a tall onboarding cliff.
The only way you get positive ROI from Nix is either you enjoy the journey, or you use it to do more than just managing a single computer: you manage a fleet, you build thin application container images, you bundle all your software, you have devshells, repeatable tests and deploys, etc. It's the same tool for all of them.
Nix is a wonderful technology. But I would not argue it is practical if you can afford "just fix it when it breaks". A nix setup more/less requires you to pay all the cost up front.
I appreciate putting in the effort now so that I don't have to later for stuff like declarative dev environments. It's really nice to not have to copy-and-paste installation instructions from a README. -- I did like the point: until you've felt what a comfortable design is, you cannot imagine it.
Yeah, I'm a Nix user and fan but I'm still going to be stuck fixing it when it breaks. The biggest thing that I have to remind myself is that reproducible != "just works." Once you get to what you want, you're set but until then and every change after, there's a chance you'll be in the weeds.
At least from my usage, the fact that your configuration is all tied to whether the entirety of nixpkgs-unstable is working can be a real headache.
Like recently when CMake was upgraded to 4.0, it took down a healthy handful of packages, which meant you couldn't update anything until things were resolved or you were really fluent in Nix hackery. (I was the former)
I have sworn off nixpkgs-unstable for basically anything but testing. I’m now on the 6 months stable release cadence and never going back. Much much better experience. Unstable really is unstable. And that’s great! But it’s not for me.
It's really easy to pull those handful of packages from an older version of nixpkgs. I had to do that when there was some buggy firmware in the latest (at the time) version of linux-firmware. You just:
1. Add a new input to your flake of nixpkgs pinned to a specific commit or branch. For example:
Thanks! I will write this down so I can try it out next time.
I really want to get better at these little things but it can be tough sometimes without concrete examples like this.
It's worth it for me. I learnt and set up my home manager config once in 2024 and I now only occasionally make light tweaks. But I deploy it on every personal computer or remote development servers at my jobs (previous and current). Granted, I'm probably one of the handful of people in my community who uses nix, because it's too arcane - but I've already paid the cost.
In the six years you are using your computer, do you ever expect to run into versioning issues and conflicts? Homebrew packages conflicting with local packages, something you compile give needs a different python/ruby/node/rust/whatever version that you have locally installed, you want to quickly try out a new package or upgrade without changing your system but have the option of rolling back safely, need to quickly install a database, want to try out a new shell and shell config but don't brick your system and have the option to roll back, etc. Nix gives you all of that and more for a one-time setup cost. Your argument is correct only if you expect to never change anything on your computer for the 6 years. But if I think about how often I have fought with homebrew or some kind of versioning/path/binary conflicts in the past then the investment in nix has paid off exponentially.
It's also about peace of mind like you said. Before nix I sometimes felt anxiety installing or upgrading certain things on my computer. "Will this upgrade break stuff?" - and often it did and I'd have to spend the next few hours debugging. With nix I don't worry about any of that anymore.
> Homebrew packages conflicting with local packages, something you compile give needs a different python/ruby/node/rust/whatever version that you have locally installed, you want to quickly try out a new package or upgrade without changing your system but have the option of rolling back safely, need to quickly install a database, want to try out a new shell and shell config but don't brick your system and have the option to roll back, etc.
Couldn't pretty much all of that be addressed using containers? Keeping your base system clean does sound wonderful, but eg distrobox containers sound more approachable - you're using all the same commands that you normally would, apps are in an environment much closer to what they probably expect. You can still roll back using snapshots, which you can configure to be automatically created on system updates. If you want an atomic rollback guarantee, and a strong reminder not to mess with the base system, you can use an immutable distro (talking about Linux, not macOS here). The one big advantage that I see from nix is reproducibility. But it's not clear how desirable that is for a desktop use case. You may actually want different software on different machines. Having an overview of all the changes you made to your system sounds cool, but I'm not sure it's worth the effort that comes with nix. I'm worried that after 8 months I'll decide it's too much hassle, like many commenters seem to do, and end up switching to a simpler system with dotfiles and containers, wishing I'd done that from the start.
That's mostly solved with env managers for python/ruby/node/..., takes at most a few minutes to fully set up and learn, and doesn't get constantly broken by macOS updates.
Even for things like trying out a new shell you can temporarily move the dotfiles somewhere and restore them back and it still takes less time than converting everything to Nix.
But now you’re stuck with Python. Nix enables trivially simple dev environments that are completely heterogenous. This gives you a powerful form of freedom because it literally opens up the entire software universe to your dev environment in a confidence inspiring way. Not to mention things like parameterising anything you use reliably and setting up environment variables, shell scripts, database service whatever you want. Also integrates with tools such as UV really well. Yes, the language is terse and difficult but once you know it, it’s liberating, and makes you a better software developer in my opinion because you now have a high-end full workshop rather than a small toolbox.
This is my feeling too. Nix is a relatively high time investment for a tool that tries to do everything, when you might not need or want everything and using the specific language’s tooling is more than sufficient and quicker. It takes a few minutes to install and do `uv sync`, or `nvm install`, or whatever, on a repository on a new computer, and it just works. Until Nix gets there, and I’m skeptical it will because of the “purist” mindset a lot of people in the community have, it’s hard to justify it.
I think the comparison is "X-as-code", like with Terraform and other tools.
If you just want a throwaway VM, it's straightforward to create one through the UI cloud console. Whereas, terraform is nevertheless still a useful tool to use to manage VMs.
For stuff like installing development dependencies.. it's maybe not difficult to copy-and-paste instructions from a readme, but solutions like devcontainers or Nix's development shells can be useful even if costing more overhead.
Of course. I wouldn’t say that Nix is a tool without much use or merit, because setting up development environments can be a huge pain and I understand why some people would use it and prefer it.
My biggest complaint is what I mentioned above: it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to - I might have to debug Nix instead of Node, which is not always straightforward. In my limited experience Nix got in my way more than I’d like, and in ways I didn’t expect or want to deal with, and until it’s as seamless as something like Homebrew or apt, it’ll be a hard sell.
> it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to
Although you're right about nix's DX being quite rough, the problem isn't exactly that it "tries to be everything for package management".
Consider the assumption Nix wants to make about its packages: it should be possible to package software by putting it in some arbitrary directory (i.e. not just /usr/bin), where its dependencies are also put in (or symlinked to) some arbitrary location.
I think with well-written software, this should be a reasonable assumption, but you're going to run into friction with that. (Friction which will require you to have a good breadth/depth of understanding).
In my experience, a lot of the complexity when dealing with Nix is with the large and organic complexity of nixpkgs.
The "trying to be everything" is more incidental to the expressive package management. -- NixOS is 'just' an OS built upon the package manager; dev shells are 'just' shells which expose the build environment of a package; etc.
Fully spot on, I don't get what is that hard to set a couple of environment variables, and mayby symbolic links, depending on the OS and language being used.
A simple UNIX script or PowerShell utility takes care of it.
None of the ones I have used during the last decades has ever grown to more than like 20 lines of code, minus comments.
until you need to start combining things. Docker is conceptually a VM the encapsulates everything nicely, but it ironically doesn't "compose" nearly as well as nix flakes or shells. With Nix you start out with a base env and can trivially extend it hierarchically and jump up and down the tree super easily, and without having to roll your own microservice architecture each time just to get stuff to work together.
Docker OTOH composes whole services nicely: if my project needs a redis cache and postgres instance, I don't have to faff about with local ports, traefik can pick up my web server, and so on. I use a flake to create and lock a local development toolchain, but it's no help in managing the services.
One thing I haven't tried yet is building a container from a flake, which would have obvious benefits for reproducibility. Still don't think it would help with service orchestration though.
> I change computers once every 6 years or so, maybe more. To me this looks like exchanging a couple (hypothetical) hours of debugging 6 years in the future by tens of (guaranteed) hours trying to climb up the nix learning cliff.
yes, it sounds like it's not worth it for you -- you will have to spend a significant amount of time converting your system to do things "the nix way". you can try to do this incrementally, but it's a time sink, and really easy to get stuck bikeshedding instead of doing work.
for me, it feels like a near equal trade-off between debugging nix, or debugging some random env issues that pop up. i know nix, claude code "knows" nix, a lot of other people online know nix. random env issues are random, and yield worse results on google, and frankly are much more frustrating to the point i would rather spend more time with nix than deal with them. maybe a very weird view.
I have experienced a positive return on investment from using Nix Darwin and devenv.sh since getting a new Mac two years ago. Did not spend too much time learning neither.
After a decade of homebrew, a few years ago I got tired of their very grumpy maintainers and switched to nix-darwin + home-manager. I've been overall fairly happy, and for tinkerers would recommend giving it a shot. Admittedly I bounced off my first try a year before that.
A few of my favorite parts, which I see less represented in this thread so far:
- I simultaneously jumped into nixos on several Linux machines (starting with a few Pis for experimentation), and maintaining all of my systems with a single flake and mostly shared code is a dream come true.
- no more convoluted dotfile syncing, most of my scripts and aliases and bash config and binaries all sync together
- cross-building linux from Darwin -- including integration tests in a vm -- works surprisingly well, this is mostly just nix but nix-darwin has helpers that make this easier
- writing system services (launchd) on my Mac then converting them to a headless Linux machine (systemd) is generally very straightforward
- prefixing my path with GNU coreutils works well and saves me from many e.g. `sed` quirks, I get expected behavior across OSes
- this was always a sore spot in homebrew, either dealing with the `g` prefix on everything (eg `gsed`) or dealing with intermittent breakages when stuff depends on the BSD behavior
- I was also able to put nix-darwin on my wife's MacBook and greatly simplify admin / maintenance tasks I do for her
- finally, the nix crew is just thirsty for help and contributions, particularly the darwin crowd; I feel like my (minor, occasional) contributions are celebrated, differences of opinion are met with an open mind, it is in general a far departure from the relative hostility of homebrew
- on the down side, I have spent far more of my limited time helping contribute to nixpkgs / nix-darwin / home-manager
I do this too. It's not for everyone. At this point it's easily been positive ROI for me, but that's after about two years now of maintaining my configs through multiple machines and MacOS upgrades.
I would recommend it only if this type of thing naturally interests you. I can't imagine powering through the initial learning curve if it felt like a frustrating chore.
That said, if having (most of) your machine defined declaratively in a git repository sounds exciting/useful/comfy, then I would encourage you to give it a try. You can start small by just configuring a few programs or options and see how you like it.
I did this for a while but MacOS updates broke Nix often enough that I usually would spent some time every week reinstalling it. I still use Nix for dev environments because it is great but Nix still breaks sometimes.
I also really wanted to like the declarative homebrew configuration but it also often didn’t work as expected for some configurations and had a lot of leaky abstractions that straight up just broke sometimes.
If I ever go back to managing my Mac with nix I would probably just do a home-manager setup and just install most of the applications imperatively.
Given this was using an intel based machine around the time when the switch to arm came so a lot of breakage also stemmed from that.
I still use nix to handle my homelab.
My setup up on my Mac is as follows:
- Orbstack
- NixOS machine run in orbstack
- My whole dev environment is run from this container and is very transportable
- GUI apps are installed on my Mac using the App Store or homebrew etc. but I try to reduce the amount of installed applications
- if I have to install something that I don’t want to install but have to, I try to do it in a UTM machine.
only thing i'd add is mas for mac app store apps you want to ensure are installed but otherwise i run pretty much the same setup.
When i install a fresh macos i have two commands to run - install nix using the determinate systems installer, then apply my nix config.
It's not quite as streamlined as nixos but good enough.
My biggest remaining pain point is dev envs - i've been leaning into adding a flake in each project, so for example i have a single project that's written in scala 2.13, when i cd into that project dir, the correct jvm version, sbt, intellij etc are installed, some useful env vars and shell aliases etc. - that's all great (i haven't felt the need to adopt denenv.sh or flox yet) but i do find myself wanting a devcontainer sandbox workflow more often these days (blame cli coding "agents"), i lean on vscode for that rather than nix so far. In python (where i spend a lot more time) uv loses a lot of value in nix and i don't like that.
Don't think of nix-darwin as an alternative to homebrew. Por que no los dos? You can run homebrew (declaratively!) via nix-darwin, and I think they complement each other quite well.
I stick to nixpkgs for most of the foundational system tools, lsps, build tools - basically anything that works in the terminal and is fully open source. For everything else (zoom, slack, vscode, firefox, etc) I use homebrew packages. The combo gives you options and is a strict superset of what you can do with homebrew or nixpkgs alone. Best of both worlds really.
There's a lot of reasons to use Nix instead of or WITH Homebrew depending on your exact needs.
Where it’s paid off for me (and where I think it actually wins) is when the problem is recreating environments: multiple machines, teammates, CI, nasty native deps, CUDA stacks, etc. At that point you’re choosing where entropy lives: in invisible drift (brew/manual installs) or in a repo you can diff/rollback.
Also, you don’t always need to go full “immutable everything.” Really depends on your needs here. Hybrid tends to be another sane path. In certain situations this can get you 80% of the upside without having to rip it all out. So kinda the "good enough" which I've seen a lot of folks do.
I tried nix-darwin for half a year, and ran into endless problems: poor docs, huge default disk usage, non-trivial to customize, etc. After 6 months, I eventually went back to a mix of Homebrew and mise, which does most of what I need for <1% of the hassle.
I still believe something like nix is the future of building software, I'm just not sure it'll be nix itself.
When I was forced to use a Mac at work I found that Nix was also just a better (mostly faster) package manager than brew. Even if you're not on the immutable bandwagon it's very worthwhile.
As a bonus I was able to achieve some semblance of uniformity across Mac and my Linux desktop with home-manager.
It would be nice to set up immutable config down to the granularity of a git commit, sharing it as a single file, and be able to reproduce that setup on anyone's machine. Instant onboarding and mirrored production (barring secrets).
Recent developments have seen the creation of bootc images for non-Fedora distros too, and at this point I've seen quite a few cool arch-bootc custom images, completely customized to the author's desires. See: https://github.com/bootcrew/, https://github.com/tartaria-dev/tartaria
I thought bootc had an open issue preventing it from working with Arch (or anything other than Fedora). Having working VMs is way further along than I expected anyone to be, this is really cool.
For me, this is the holy grail. Every time I switch laptops, I lift all my config files and such over, but there's always so many system level configs and other things that you have to go and manually fiddle. On top of that, some apps don't really behave well when you just move config files to e.g. under a different username etc. Would be nice if there was a comprehensive solution to this problem, need to try nix-darwin out.
nix-darwin is essentially this. I have a small bootstrap script to install Xcode CLI and Nix, git clone my dotfiles and activate the config. That in turn sets up the system, also installs Homebrew, installs apps from the App store and sets up all my configs. The only thing I need to do after is sign into some accounts.
Speaking from the viewpoint of a whole operating system images, the main challenge is that while Nix allows you to create ephemeral environments, many people (myself included) have various hard-coded paths for mounting hard drives. If you want something to be shareable, you have to create a workflow in which the user environment is activated interactively after a tty session is acquired. Same goes for any system services that need persistence -- these have to be configured to be activated at runtime. It's a lot of work for a party-trick. It's probably possible to configure the system such that the log-in needs a FIDO2 key which is also used for LUKS drives, which would be similar to how macOS handles log-ins. But abstracting this such the login works on every machine possible suddenly requires filesystems to be networked, and so on.
That being said, we used NixOS images to boot several Windows PCs of my friends into RAM to play Halo 3 multiplayer split-screen. Most of my friends were mainly confused why they could play with any gamepad they had in their shelf. They also left the event with no permanent changes to their PCs.
I haven't used Nix yet, but I have done exactly this a number of times with Guix now. I assume Nix has the same capabilities. In Guix you can specify a home configuration that includes packages, configuration files, and running services all in one manifest.scm file. If you want to make sure that it's isolated from whatever else is set up on the system you can launch that manifest in a container with a single extra flag
this is basically the purpose of nix flakes, which take in inputs (usually git repositories) and provide outputs (compiled files, docker images, etc). it's a pain to get going, but not tremendously difficult with some googling. It's a lot easier with AI as well.
Ive been using nix-darwin for over a year now after using nixos with flakes for a bit. I now have a singular repo with multiple machine configurations. Nixos for my home server, nix darwin on a macbook air and a nix darwin with a work config. This allows me to have common programs on all machines but also overlay some specialised packages and programs in certain environments. After climbing the initial mountain, its been very satisfying and things just work. My work laptop died recently and I was able to be fully up to speed in a fraction of the time it would have taken me otherwise.
The real game changer after I went full nix OS on all my machines and using it on a a few Mac’s is indeed devshells which seemed so annoying to learn but really really are a game changer
Installed nix-darwin on 26.0, on a fresh M4 air. I have updated since updated macos to 26.2 through the normal method, no wacky nix stuff there. no issues. no clue on major version changes, but nix-darwin is essentially the nix config language parsed to then run the necessary set of scripts.
Are folks not using migration assistant when they get a new Mac? I’ve had the “same” macOS install for almost 20 years, across 6 or 7 machines, and it’s fine. I see the value of nix-darwin if you use multiple Macs and change them frequently, but that’s never been me.
Right, these commercial operating systems are designed with a different philosophy that arguably has its own merit.
I’m enjoying a Fedora atomic distribution for the eliminating the Linux upgrading issues of the past. But macOS and Windows never really had that problem.
I’m using nix to set up both my dev laptop (macOS) but also my self-hosting/homelab (NixOS). It works really well, and nice to have one way to set stuff up. And they are both synced up with the stuff I want to be mirrored across systems.
Interesting, and good luck to OP. I feel a little clickbaited, cause I was hoping for a port of stateless infra (although it may be of little use on a (dev machine :p) [1]
Looking in from outside, people going immutable with Nix sure seem to struggle a lot more than people going immutable with disposable containers and Terraform/OpenTofu
I see these kind of posts like using Gentoo, cool that some people are having fun, not for me, using computers the mid-80's I have better yaks to shave.
I am critical as with any technology (see my comment about Nix in another thread here), but Nix is profoundly not using computers the mid-80's way. It is more future technology, where a system is immutable, fully declaratively defined, has atomic updates/rollback, etc. It's the direction things are going, see e.g. macOS sealed system volumes, Fedora Silverblue, etc. It's just that it still has a very large number of sharp edges, not so great documentation, lack of static typing, etc.
Nix may not be the tech that replaces everything, but at the very least it is and has been an important exploration vehicle for declarative configuration, immutable systems, etc.
A useful way to frame this isn’t “is it worth tens of hours to avoid a future reinstall” but “where do I want my entropy to live”. You’re going to invest time somewhere: either in a slowly-accumulating pile of invisible state (brew, manual configs, random installers) or in a config that you can diff, review and roll back. The former feels free until you hit some cursed PATH/SSL/toolchain issue at 11pm and realize you’ve been paying that tax all along, just in tiny, forgotten increments.
I think where Nix shines isn’t “one laptop every 6 years” but when your environment needs to be shared or recreated: multiple machines, a team, or a project with nasty native deps. At that point, nix-darwin + dev shells becomes infrastructure, not a hobby. You don’t have to go all-in on “my whole Mac is Nix” either: keep GUI apps and casual tools imperative, and treat Nix as the source of truth for the stuff that actually blocks you from doing work. That hybrid model matches what the article hints at and tends to give you most of the upside without turning your personal laptop into a second job.
One of the biggest annoyances I have with doing this with Nix vs another tool is that Nix doesn't natively communicate back state changes so that you can make them reproducible.
If I make a git repo, place '~/.config/newsapp.conf' in there and then symlink it back to '~/.config/', if NewsApp introduces a new variable in its settings I am immediately aware because Git will complain about being dirty. However, Nix will happily just nuke that .conf and rebuild whatever is in your configuration, without letting you know about state. Which is ultimately bad for reproducibility. It's a huge blind spot in Nix.
I tried getting Nix working a couple of months ago and ditched it because changing some Tower settings updates the global gitconfig (as it should in this circumstance) and Nix would wipe them out.
All of it seemed way too annoying compared to just having a dotfiles repo, and if it couldn’t handle the Tower/gitconfig issue I know for sure everything else I was going to run into wasn’t worth it.
For what it's worth, you can put a git repo inside a nix configuration / flake folder and it will tell you the repo is dirty. 'nh' also has commands to tell you about state. But it shouldn't require outside tools.
The way I do it is have config files in my Nix config folder, then use Nix to symlink them and I use git to make me aware of state changes, that I might want to make reproducible. But that's just me being used to my old git ways, using 'nh' gives much more clarity.
The "true" Nix way is putting the entire contents of whatever config file in a .nix file, then erasing the original config and have Nix recreate the config (preferably read-only) in place. You become truly reproducible but for obvious reasons applications get mad when you make their config file read only.
This really hinges on whether you let state accumulate, and where you let it do so. NixOS generally creates a dedicated user and data directory for its services, for example. I make some of my XDG config directories symlinks to the nix store because I want those configurations to be read-only. home-manager should ask before making modifications outside of the nix store (or make a backup).
This is not only a Nix problem, fwiw. I first encountered this with, say, running ZNC in Docker. It will happily write logs and configs to a temporary directory in the container and get blown away on restart unless you mount persistent volumes in just the right spots. Syncthing can be configured to manage its own config or it can be configured fully by Nix, etc.
It sounds like you're talking about home-manager, which is a third-party Nix module, not Nix itself. I've been using Nix happily for several years now for work and personal without needing to use home-manager at all (since I don't like it either).
It was just an example. Other packages could also set new variables / parameters in their configuration. It might not be a problem in the beginning if the variable is just repopulated, but it might blow up in your face in the future.
If you use Nix you're completely blind to that unless you A) religiously check your state or B) use another tool like 'git' or 'nh'. Like I said, it's a blind spot, both figuratively and literally.
This problem may be specific to Darwin because on NixOS I've never had a file overwritten by nix (even with home manager). When a file is managed by nix it's a symlink to a read-only filesystem (/nix/store), so no program can overwrite it. If the symlink is replaced by a regular file, nix refuses to reapply.
Correct for data, not for config files. Config files are stateful unless you do the procedure I mentioned, because they're generated at first application launch.
If you try to symlink into an existing file Nix will indeed complain, which is why you have to erase the config file and then put yours in place. You can either write it out from a .nix file (pure reproducibility) or from symlink copy from a file managed by git (technically impure but effectively reproducible).
But my config files (/etc, ~/.config, etc.) are either managed by nix (and no program can modify them), or they are not and in that case nix will never touch them. In what situation would nix overwrite a file?
Actually Nix even errors out if the file it tries to write is already in place. I have this sometimes when I move fish functions from being defined adhoc with funcsave to putting them in my nix config because I want them on all my machines.
>I think where Nix shines isn’t “one laptop every 6 years” but when your environment needs to be shared or recreated: multiple machines, a team, or a project with nasty native deps.
I'd like to add the third thing, which is just iteration. It's very tricky to maintain advanced workflows even locally. I'd guess many won't even try to compose things that could work in combination (often self-hosted services), when they know they can't reliably maintain those environments.
> keep GUI apps and casual tools imperative, and treat Nix as the source of truth for the stuff that actually blocks you from doing work
I landed somewhere similar for gaming.
When I first got my Legion Go, there were a whole bunch of gaming distros, but none was more popular than the other. I read a bit about immutability, got curious, and installed Jovian-NixOS (which is to NixOS what Bazzite is to Fedora).
I liked that it gave me the Steam Deck experience on unofficial hardware, and it was neat to be able to play with e.g. replacing the desktop shell. However, a keyboard-centric configuration scheme is a bad pairing for a touch-centric device. Little things, like changing the timezone, became needlessly frictionful.
Now I'm on the official SteamOS, with Nix as the package manager. It seems to be a good pairing. Nix lets me install Linux utilities on Steam's otherwise-immutable filesystem. And I can use the Steam UI to change things like the time.
I'll probably write an article in the next few weeks on using Nix to make Linux-native copies of Windows-built games.
I've tried nix-darwin a time or two in the past. Every few years when homebrew makes a "hostile" change and I get upset I consider trying it again (now most recently with changes to gatekeeper). I think I'll get to doing so in the next year or so.
But I think just in fairness, the comparison here for flakes should be to Homebrew bundles. My packages are managed in a bundle: https://github.com/Julian/dotfiles/blob/main/Brewfile and then locked by a lockfile: https://github.com/Julian/dotfiles/blob/main/Brewfile.lock.j... and installing is just `brew bundle install`. All native Homebrew functionality. In practice I have never had an issue with non-reproducible builds across my machines (partly because the tendency on macOS is to run the latest versions of things and stay up to date).
(But again I do find nix-darwin interesting to try for other reasons.)
Very nice, I think I'll be moving my "must-have" homebrew packages to a Brewfile. FYI tho, Homebrew no longer supports Brewfile.lock.json (it was always just a log anyway, not a lockfile). https://github.com/Homebrew/homebrew-bundle/pull/1509
Fun, thanks for letting me know, will remove it :)
(I'll still stick with "I never really have run into a version issue for things I use Homebrew for, for places where it matters, I have whatever-programming-language-lockfile-for-the-project-I-am-developing" for cases where I need to be sure the setup is reproducible, which is why I've clearly never noticed this file was useless).
> the comparison here for flakes should be to Homebrew bundles.
The bundler integration for nix-darwin actually just bakes tightly-controlled Brewfiles. It’s still worthwhile though, since part of the “tightly-controlled” means better cleanup when you remove things.
I see this:
> The consequence is me, spending a few hours debugging my environment instead of writing code.
But then I also see this:
> I’ve spent a lot of time recently moving my entire workflow into a declarative system using nix.
I can see how this can be beneficial for someone who switches systems very often, reinstalls their OS from scratch very often, or just derives a lot of pleasure/peace of mind knowing that their dev env is immutable.
I change computers once every 6 years or so, maybe more. To me this looks like exchanging a couple (hypothetical) hours of debugging 6 years in the future by tens of (guaranteed) hours trying to climb up the nix learning cliff.
I am happy that it works for the author though, and knowing that it's possible is good in case my particular development circumstances change.
Long-time (by now) Nix user here. It's even worse than a few hours of debugging. In my experience it requires continuous maintenance, options tend to be deprecated and moved around on a regular basis (at least in NixOS and home-manager), things like NeoVim break regularly as a result of friction between the immutable world and a lot of plugins expecting a mutable world, etc. I do install my Mac from scratch every 6 months or so (I like a clean system), but with a dotfiles repo and Homebrew, it takes me about an hour to set everything up again, which is far less time than maintaining a Nix-managed system.
For me Nix/NixOS is by far the most effective for deploying servers, development VMs, etc. I do this regularly, so it pays off - I have a familiar environment completely set up in minutes. Another place it pays off, even on macOS, is for development environments, especially if you have to pull in a lot of native dependencies (which can happen in mixed Python + C++ projects, mixed Rust + C/C++ projects, etc.).
Nix shines in all difficult cases, like setting up complex cross-compilation environments, building for old glibc versions, etc. You set it up once and then it's really easy for yourself and other project contributors to get the same build environment.
Like any tool, a good engineer knows when to apply it.
It sounds like you're on unstable? Things are significantly more stable if you stick to the release branches (25.05, 25.11 etc)
> I do install my Mac from scratch every 6 months or so (I like a clean system), but with a dotfiles repo and Homebrew, it takes me about an hour to set everything up again, which is far less time than maintaining a Nix-managed system.
Er, YMMV I guess? IMO if you're spending more than an hour fussing with it per 6 months, you're doing something weird
Nix is not worth it if all you want is configuring your home computer. The learning curve is steep and has a tall onboarding cliff.
The only way you get positive ROI from Nix is either you enjoy the journey, or you use it to do more than just managing a single computer: you manage a fleet, you build thin application container images, you bundle all your software, you have devshells, repeatable tests and deploys, etc. It's the same tool for all of them.
Right.
Nix is a wonderful technology. But I would not argue it is practical if you can afford "just fix it when it breaks". A nix setup more/less requires you to pay all the cost up front.
I appreciate putting in the effort now so that I don't have to later for stuff like declarative dev environments. It's really nice to not have to copy-and-paste installation instructions from a README. -- I did like the point: until you've felt what a comfortable design is, you cannot imagine it.
Yeah, I'm a Nix user and fan but I'm still going to be stuck fixing it when it breaks. The biggest thing that I have to remind myself is that reproducible != "just works." Once you get to what you want, you're set but until then and every change after, there's a chance you'll be in the weeds.
At least from my usage, the fact that your configuration is all tied to whether the entirety of nixpkgs-unstable is working can be a real headache. Like recently when CMake was upgraded to 4.0, it took down a healthy handful of packages, which meant you couldn't update anything until things were resolved or you were really fluent in Nix hackery. (I was the former)
I have sworn off nixpkgs-unstable for basically anything but testing. I’m now on the 6 months stable release cadence and never going back. Much much better experience. Unstable really is unstable. And that’s great! But it’s not for me.
It's really easy to pull those handful of packages from an older version of nixpkgs. I had to do that when there was some buggy firmware in the latest (at the time) version of linux-firmware. You just:
1. Add a new input to your flake of nixpkgs pinned to a specific commit or branch. For example:
2. Add an overlay where you replace those packages with versions from the older nixpkgs. For example:Thanks! I will write this down so I can try it out next time. I really want to get better at these little things but it can be tough sometimes without concrete examples like this.
It's worth it for me. I learnt and set up my home manager config once in 2024 and I now only occasionally make light tweaks. But I deploy it on every personal computer or remote development servers at my jobs (previous and current). Granted, I'm probably one of the handful of people in my community who uses nix, because it's too arcane - but I've already paid the cost.
In the six years you are using your computer, do you ever expect to run into versioning issues and conflicts? Homebrew packages conflicting with local packages, something you compile give needs a different python/ruby/node/rust/whatever version that you have locally installed, you want to quickly try out a new package or upgrade without changing your system but have the option of rolling back safely, need to quickly install a database, want to try out a new shell and shell config but don't brick your system and have the option to roll back, etc. Nix gives you all of that and more for a one-time setup cost. Your argument is correct only if you expect to never change anything on your computer for the 6 years. But if I think about how often I have fought with homebrew or some kind of versioning/path/binary conflicts in the past then the investment in nix has paid off exponentially.
It's also about peace of mind like you said. Before nix I sometimes felt anxiety installing or upgrading certain things on my computer. "Will this upgrade break stuff?" - and often it did and I'd have to spend the next few hours debugging. With nix I don't worry about any of that anymore.
> Homebrew packages conflicting with local packages, something you compile give needs a different python/ruby/node/rust/whatever version that you have locally installed, you want to quickly try out a new package or upgrade without changing your system but have the option of rolling back safely, need to quickly install a database, want to try out a new shell and shell config but don't brick your system and have the option to roll back, etc.
Couldn't pretty much all of that be addressed using containers? Keeping your base system clean does sound wonderful, but eg distrobox containers sound more approachable - you're using all the same commands that you normally would, apps are in an environment much closer to what they probably expect. You can still roll back using snapshots, which you can configure to be automatically created on system updates. If you want an atomic rollback guarantee, and a strong reminder not to mess with the base system, you can use an immutable distro (talking about Linux, not macOS here). The one big advantage that I see from nix is reproducibility. But it's not clear how desirable that is for a desktop use case. You may actually want different software on different machines. Having an overview of all the changes you made to your system sounds cool, but I'm not sure it's worth the effort that comes with nix. I'm worried that after 8 months I'll decide it's too much hassle, like many commenters seem to do, and end up switching to a simpler system with dotfiles and containers, wishing I'd done that from the start.
That's mostly solved with env managers for python/ruby/node/..., takes at most a few minutes to fully set up and learn, and doesn't get constantly broken by macOS updates.
Even for things like trying out a new shell you can temporarily move the dotfiles somewhere and restore them back and it still takes less time than converting everything to Nix.
But now you’re stuck with Python. Nix enables trivially simple dev environments that are completely heterogenous. This gives you a powerful form of freedom because it literally opens up the entire software universe to your dev environment in a confidence inspiring way. Not to mention things like parameterising anything you use reliably and setting up environment variables, shell scripts, database service whatever you want. Also integrates with tools such as UV really well. Yes, the language is terse and difficult but once you know it, it’s liberating, and makes you a better software developer in my opinion because you now have a high-end full workshop rather than a small toolbox.
This is my feeling too. Nix is a relatively high time investment for a tool that tries to do everything, when you might not need or want everything and using the specific language’s tooling is more than sufficient and quicker. It takes a few minutes to install and do `uv sync`, or `nvm install`, or whatever, on a repository on a new computer, and it just works. Until Nix gets there, and I’m skeptical it will because of the “purist” mindset a lot of people in the community have, it’s hard to justify it.
I think the comparison is "X-as-code", like with Terraform and other tools.
If you just want a throwaway VM, it's straightforward to create one through the UI cloud console. Whereas, terraform is nevertheless still a useful tool to use to manage VMs.
For stuff like installing development dependencies.. it's maybe not difficult to copy-and-paste instructions from a readme, but solutions like devcontainers or Nix's development shells can be useful even if costing more overhead.
Of course. I wouldn’t say that Nix is a tool without much use or merit, because setting up development environments can be a huge pain and I understand why some people would use it and prefer it.
My biggest complaint is what I mentioned above: it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to - I might have to debug Nix instead of Node, which is not always straightforward. In my limited experience Nix got in my way more than I’d like, and in ways I didn’t expect or want to deal with, and until it’s as seamless as something like Homebrew or apt, it’ll be a hard sell.
> it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to
Although you're right about nix's DX being quite rough, the problem isn't exactly that it "tries to be everything for package management".
Consider the assumption Nix wants to make about its packages: it should be possible to package software by putting it in some arbitrary directory (i.e. not just /usr/bin), where its dependencies are also put in (or symlinked to) some arbitrary location.
I think with well-written software, this should be a reasonable assumption, but you're going to run into friction with that. (Friction which will require you to have a good breadth/depth of understanding).
In my experience, a lot of the complexity when dealing with Nix is with the large and organic complexity of nixpkgs.
The "trying to be everything" is more incidental to the expressive package management. -- NixOS is 'just' an OS built upon the package manager; dev shells are 'just' shells which expose the build environment of a package; etc.
Fully spot on, I don't get what is that hard to set a couple of environment variables, and mayby symbolic links, depending on the OS and language being used.
A simple UNIX script or PowerShell utility takes care of it.
None of the ones I have used during the last decades has ever grown to more than like 20 lines of code, minus comments.
> Even for things like trying out a new shell you can temporarily move the dotfiles somewhere and restore them back...
I think the closest mainstream UX for "you can try out this program without having to install it" is running a Docker image.
:) I'd say Nix is second best at everything related to packages.
until you need to start combining things. Docker is conceptually a VM the encapsulates everything nicely, but it ironically doesn't "compose" nearly as well as nix flakes or shells. With Nix you start out with a base env and can trivially extend it hierarchically and jump up and down the tree super easily, and without having to roll your own microservice architecture each time just to get stuff to work together.
Docker OTOH composes whole services nicely: if my project needs a redis cache and postgres instance, I don't have to faff about with local ports, traefik can pick up my web server, and so on. I use a flake to create and lock a local development toolchain, but it's no help in managing the services.
One thing I haven't tried yet is building a container from a flake, which would have obvious benefits for reproducibility. Still don't think it would help with service orchestration though.
> I change computers once every 6 years or so, maybe more. To me this looks like exchanging a couple (hypothetical) hours of debugging 6 years in the future by tens of (guaranteed) hours trying to climb up the nix learning cliff.
yes, it sounds like it's not worth it for you -- you will have to spend a significant amount of time converting your system to do things "the nix way". you can try to do this incrementally, but it's a time sink, and really easy to get stuck bikeshedding instead of doing work.
for me, it feels like a near equal trade-off between debugging nix, or debugging some random env issues that pop up. i know nix, claude code "knows" nix, a lot of other people online know nix. random env issues are random, and yield worse results on google, and frankly are much more frustrating to the point i would rather spend more time with nix than deal with them. maybe a very weird view.
I have experienced a positive return on investment from using Nix Darwin and devenv.sh since getting a new Mac two years ago. Did not spend too much time learning neither.
Also with migration assistant on Mac you basically do not need this in anyway shape or form.
After a decade of homebrew, a few years ago I got tired of their very grumpy maintainers and switched to nix-darwin + home-manager. I've been overall fairly happy, and for tinkerers would recommend giving it a shot. Admittedly I bounced off my first try a year before that.
A few of my favorite parts, which I see less represented in this thread so far:
- I simultaneously jumped into nixos on several Linux machines (starting with a few Pis for experimentation), and maintaining all of my systems with a single flake and mostly shared code is a dream come true. - no more convoluted dotfile syncing, most of my scripts and aliases and bash config and binaries all sync together - cross-building linux from Darwin -- including integration tests in a vm -- works surprisingly well, this is mostly just nix but nix-darwin has helpers that make this easier - writing system services (launchd) on my Mac then converting them to a headless Linux machine (systemd) is generally very straightforward - prefixing my path with GNU coreutils works well and saves me from many e.g. `sed` quirks, I get expected behavior across OSes - this was always a sore spot in homebrew, either dealing with the `g` prefix on everything (eg `gsed`) or dealing with intermittent breakages when stuff depends on the BSD behavior - I was also able to put nix-darwin on my wife's MacBook and greatly simplify admin / maintenance tasks I do for her - finally, the nix crew is just thirsty for help and contributions, particularly the darwin crowd; I feel like my (minor, occasional) contributions are celebrated, differences of opinion are met with an open mind, it is in general a far departure from the relative hostility of homebrew - on the down side, I have spent far more of my limited time helping contribute to nixpkgs / nix-darwin / home-manager
I do this too. It's not for everyone. At this point it's easily been positive ROI for me, but that's after about two years now of maintaining my configs through multiple machines and MacOS upgrades.
I would recommend it only if this type of thing naturally interests you. I can't imagine powering through the initial learning curve if it felt like a frustrating chore.
That said, if having (most of) your machine defined declaratively in a git repository sounds exciting/useful/comfy, then I would encourage you to give it a try. You can start small by just configuring a few programs or options and see how you like it.
I wrote more about my experience here where I also link to my configs: https://bryce.is/writing/code/fully-nix-pilled
I did this for a while but MacOS updates broke Nix often enough that I usually would spent some time every week reinstalling it. I still use Nix for dev environments because it is great but Nix still breaks sometimes.
I also really wanted to like the declarative homebrew configuration but it also often didn’t work as expected for some configurations and had a lot of leaky abstractions that straight up just broke sometimes.
If I ever go back to managing my Mac with nix I would probably just do a home-manager setup and just install most of the applications imperatively.
Given this was using an intel based machine around the time when the switch to arm came so a lot of breakage also stemmed from that.
I still use nix to handle my homelab.
My setup up on my Mac is as follows:
- Orbstack
- NixOS machine run in orbstack
- My whole dev environment is run from this container and is very transportable
- GUI apps are installed on my Mac using the App Store or homebrew etc. but I try to reduce the amount of installed applications
- if I have to install something that I don’t want to install but have to, I try to do it in a UTM machine.
Try dra[1] and a simple shell script in your dotfiles that installs / updates everything in
along with extending the $PATH. Works great for most of my tools (exa, zoxide, bat, jq, etc).1: https://github.com/devmatteini/dra
I’ll check it out thanks :)
I found the Brewfile and a little `setup.sh` to be more than sufficient for getting a new Mac setup.
only thing i'd add is mas for mac app store apps you want to ensure are installed but otherwise i run pretty much the same setup.
When i install a fresh macos i have two commands to run - install nix using the determinate systems installer, then apply my nix config.
It's not quite as streamlined as nixos but good enough.
My biggest remaining pain point is dev envs - i've been leaning into adding a flake in each project, so for example i have a single project that's written in scala 2.13, when i cd into that project dir, the correct jvm version, sbt, intellij etc are installed, some useful env vars and shell aliases etc. - that's all great (i haven't felt the need to adopt denenv.sh or flox yet) but i do find myself wanting a devcontainer sandbox workflow more often these days (blame cli coding "agents"), i lean on vscode for that rather than nix so far. In python (where i spend a lot more time) uv loses a lot of value in nix and i don't like that.
Don't think of nix-darwin as an alternative to homebrew. Por que no los dos? You can run homebrew (declaratively!) via nix-darwin, and I think they complement each other quite well.
I stick to nixpkgs for most of the foundational system tools, lsps, build tools - basically anything that works in the terminal and is fully open source. For everything else (zoom, slack, vscode, firefox, etc) I use homebrew packages. The combo gives you options and is a strict superset of what you can do with homebrew or nixpkgs alone. Best of both worlds really.
The article I used to help set up, in case this helps anyone: https://davi.sh/blog/2024/01/nix-darwin/
[Disclaimer: biased Flox/Nix person]
There's a lot of reasons to use Nix instead of or WITH Homebrew depending on your exact needs.
Where it’s paid off for me (and where I think it actually wins) is when the problem is recreating environments: multiple machines, teammates, CI, nasty native deps, CUDA stacks, etc. At that point you’re choosing where entropy lives: in invisible drift (brew/manual installs) or in a repo you can diff/rollback.
Also, you don’t always need to go full “immutable everything.” Really depends on your needs here. Hybrid tends to be another sane path. In certain situations this can get you 80% of the upside without having to rip it all out. So kinda the "good enough" which I've seen a lot of folks do.
We (Flox) actually worked on this with Kelsey Hightower a while back - https://bsky.app/profile/kelseyhightower.com/post/3ld2rsccls...
I tried nix-darwin for half a year, and ran into endless problems: poor docs, huge default disk usage, non-trivial to customize, etc. After 6 months, I eventually went back to a mix of Homebrew and mise, which does most of what I need for <1% of the hassle.
I still believe something like nix is the future of building software, I'm just not sure it'll be nix itself.
When I was forced to use a Mac at work I found that Nix was also just a better (mostly faster) package manager than brew. Even if you're not on the immutable bandwagon it's very worthwhile.
As a bonus I was able to achieve some semblance of uniformity across Mac and my Linux desktop with home-manager.
It would be nice to set up immutable config down to the granularity of a git commit, sharing it as a single file, and be able to reproduce that setup on anyone's machine. Instant onboarding and mirrored production (barring secrets).
With the caveat of it not being a portable single file, I find custom image-based Linuxes fill this gap perfectly.
There's of course Fedora Silverblue / Fedora Bootc with https://universal-blue.org/ and https://blue-build.org/ being good examples.
Recent developments have seen the creation of bootc images for non-Fedora distros too, and at this point I've seen quite a few cool arch-bootc custom images, completely customized to the author's desires. See: https://github.com/bootcrew/, https://github.com/tartaria-dev/tartaria
I thought bootc had an open issue preventing it from working with Arch (or anything other than Fedora). Having working VMs is way further along than I expected anyone to be, this is really cool.
For me, this is the holy grail. Every time I switch laptops, I lift all my config files and such over, but there's always so many system level configs and other things that you have to go and manually fiddle. On top of that, some apps don't really behave well when you just move config files to e.g. under a different username etc. Would be nice if there was a comprehensive solution to this problem, need to try nix-darwin out.
nix-darwin is essentially this. I have a small bootstrap script to install Xcode CLI and Nix, git clone my dotfiles and activate the config. That in turn sets up the system, also installs Homebrew, installs apps from the App store and sets up all my configs. The only thing I need to do after is sign into some accounts.
Speaking from the viewpoint of a whole operating system images, the main challenge is that while Nix allows you to create ephemeral environments, many people (myself included) have various hard-coded paths for mounting hard drives. If you want something to be shareable, you have to create a workflow in which the user environment is activated interactively after a tty session is acquired. Same goes for any system services that need persistence -- these have to be configured to be activated at runtime. It's a lot of work for a party-trick. It's probably possible to configure the system such that the log-in needs a FIDO2 key which is also used for LUKS drives, which would be similar to how macOS handles log-ins. But abstracting this such the login works on every machine possible suddenly requires filesystems to be networked, and so on.
That being said, we used NixOS images to boot several Windows PCs of my friends into RAM to play Halo 3 multiplayer split-screen. Most of my friends were mainly confused why they could play with any gamepad they had in their shelf. They also left the event with no permanent changes to their PCs.
I haven't used Nix yet, but I have done exactly this a number of times with Guix now. I assume Nix has the same capabilities. In Guix you can specify a home configuration that includes packages, configuration files, and running services all in one manifest.scm file. If you want to make sure that it's isolated from whatever else is set up on the system you can launch that manifest in a container with a single extra flag
this is basically the purpose of nix flakes, which take in inputs (usually git repositories) and provide outputs (compiled files, docker images, etc). it's a pain to get going, but not tremendously difficult with some googling. It's a lot easier with AI as well.
Ive been using nix-darwin for over a year now after using nixos with flakes for a bit. I now have a singular repo with multiple machine configurations. Nixos for my home server, nix darwin on a macbook air and a nix darwin with a work config. This allows me to have common programs on all machines but also overlay some specialised packages and programs in certain environments. After climbing the initial mountain, its been very satisfying and things just work. My work laptop died recently and I was able to be fully up to speed in a fraction of the time it would have taken me otherwise.
The real game changer after I went full nix OS on all my machines and using it on a a few Mac’s is indeed devshells which seemed so annoying to learn but really really are a game changer
How well does nix-darwin survive macOS updates?
Installed nix-darwin on 26.0, on a fresh M4 air. I have updated since updated macos to 26.2 through the normal method, no wacky nix stuff there. no issues. no clue on major version changes, but nix-darwin is essentially the nix config language parsed to then run the necessary set of scripts.
I installed on macos14? Maybe 13? And have had minimal trouble since.
Comparable to the amount of breakage I regularly had with homebrew.
Are folks not using migration assistant when they get a new Mac? I’ve had the “same” macOS install for almost 20 years, across 6 or 7 machines, and it’s fine. I see the value of nix-darwin if you use multiple Macs and change them frequently, but that’s never been me.
Right, these commercial operating systems are designed with a different philosophy that arguably has its own merit.
I’m enjoying a Fedora atomic distribution for the eliminating the Linux upgrading issues of the past. But macOS and Windows never really had that problem.
I’m using nix to set up both my dev laptop (macOS) but also my self-hosting/homelab (NixOS). It works really well, and nice to have one way to set stuff up. And they are both synced up with the stuff I want to be mirrored across systems.
What we should be talking about is how to get rid Apple ecosystem all together.
You can just not use it at all, there are alternatives.
Why do you want to get rid of something which you are not forced to use?
Interesting, and good luck to OP. I feel a little clickbaited, cause I was hoping for a port of stateless infra (although it may be of little use on a (dev machine :p) [1]
1: https://grahamc.com/blog/erase-your-darlings/
Looking in from outside, people going immutable with Nix sure seem to struggle a lot more than people going immutable with disposable containers and Terraform/OpenTofu
How do you manage macOS desktop apps with those, I am confused. The article is about set up of a personal workspace.
I see these kind of posts like using Gentoo, cool that some people are having fun, not for me, using computers the mid-80's I have better yaks to shave.
I am critical as with any technology (see my comment about Nix in another thread here), but Nix is profoundly not using computers the mid-80's way. It is more future technology, where a system is immutable, fully declaratively defined, has atomic updates/rollback, etc. It's the direction things are going, see e.g. macOS sealed system volumes, Fedora Silverblue, etc. It's just that it still has a very large number of sharp edges, not so great documentation, lack of static typing, etc.
Nix may not be the tech that replaces everything, but at the very least it is and has been an important exploration vehicle for declarative configuration, immutable systems, etc.
Immutable systems have zero to do with Nix, a common source of inspiration maybe, that is all.
So I will be doing configuraions instead of work. Thanks but no thanks.
This is just procrastination.