What nixpkgs branch should I track in my system configuration flake?

Currently I’m only configuring a darwin system, so I was following the nixpkgs-21.11-darwin branch in my flake. But is this right? Looking at the list of active branches on the nixpkgs repo, I’m now wondering if I should be using release-21.11. My (naive) reasoning is:

  • nixpkgs-21.11-darwin seems overly specific for the flake input, which I might want to have cover multiple operating systems in the future
  • release-21.11 sounds like it is meant to be more operating-system agnostic
  • release-21.11 matches the name of the home-manager branch I’m tracking in my flake inputs
  • release-21.11 seems more actively updated than nixpkgs-21.11-darwin

Sorry if this is a simple question, I was a little bewildered by the nixpkgs branches, and couldn’t find any specific pointers in the README, which only talks about branches with respect to contributions.

The release-* branches are not meant for use, they are just to be used as merge targets for backports.

Best, but not perfect, system agnostic is probably nixpkgs-* branches.

Ahh gotcha, thanks! So would that be nixpkgs-unstable? It seems like the only system-agnostic one: Branches · NixOS/nixpkgs · GitHub - or was I right all along to be using the nixpkgs-*-darwin one? :sweat_smile:

As I understand it, the only thing system-specific in a branch is what constitutes a blocker for updating it. You could use nixpks-21.11-darwin with NixOS, but there would be a risk that sometimes it could be broken for NixOS because that isn’t use to block updates to the branch. The same is true of nixos-21.11 except the other way.

Personally, I just use nixos-21.11 for everything and accept that sometimes Darwin may be broken. It’s pretty uncommon though. I think that’s happened only a handful of times to me in the last year or so. Since I update my Darwin systems manually and NixOS ones automatically, that’s fine. I want my NixOS systems to just work. I can live with the occasional Darwin breakage.


How do you generally handle/work-around breakages on Darwin?

It depends. I track both stable and unstable channels. Most of the breakage has happen on unstable. I usually wait it out, but sometimes I need to include a workaround in my config. If I can, I also try to open a PR (though that is fixing builds on Darwin that never built).

Two stable breakages come to mind. The first was when fish was changed to use fishPlugins.foreign-env. I had to use a workaround in my configs until nix-darwin was updated to handle it. The same happened with a change to nixUnstable that replaced nix info with nix metadata. Otherwise, they’re pretty rare.

Unstable breakages are more common. I was using rust-analyzer from unstable for a while, and I had to override rustPlatform from unstable with one from stable because Rust had problems building on Darwin for a while.

Oh, there is another kind of stable breakage. Sometimes things build on x86_64-darwin but are broken on aarch64-darwin. It usually suffices to pull them in from unstable (otherwise I may try to fix the build and open a PR). 21.11 has been a lot better than that. Currently, the only things I’m pulling from unstable are PRs I opened too late to make 21.11 (and nix_2_5).

1 Like

Cheers, that’s really helpful! It’s very useful to know what I’m getting into, and nice to know there are workarounds that can be done if I run into these issues in the wild.

It doesn’t seem any worse than what I’m currently dealing with – I’m running into some breakages with Lean 4 on my aarch64-darwin system (something to do with codesign_allocate failing to spawn), and I’ve got a goofy workaround for nix-direnv that seems to have not to have been fixed in the release I’m tracking.

1 Like

goofy workaround for nix-direnv

Huh. I had noticed those sed messages but hadn’t dug into what was causing them since things still seemed to work.

/me copies fix