I received a new Mac Mini M4 today and am looking to do a complete fresh install of macOS, Nix, and all the various Nix tools that I use. I have the following in mind:

1. Install Nix with the experimental/beta installer.
2. Install (standalone) Home Manager (existing, shared cross-platform configuration)
3. Install Nix Darwin
4. Setup a Linux Builder with Nix Darwin
5. Setup a UTM VM with NixOS w/GUI

I received a new Mac Mini M4 today and am looking to do a complete fresh install of macOS, Nix, and all the various Nix tools that I use. I have the following in mind:

1. Install Nix with the experimental/beta installer.
2. Install (standalone) Home Manager (existing, shared cross-platform configuration)
3. Install Nix Darwin
4. Setup a Linux Builder with Nix Darwin
5. Setup a UTM VM with NixOS w/GUI

(Oops, I'm still editing this didn't mean to submit, give me a few minutes to finish...)

I received a new Mac Mini M4 today and am looking to do a complete fresh install of macOS, Nix, and all the various Nix tools that I use. I have the following in mind:

1. Install Nix with the experimental/beta installer.
2. Install (standalone) Home Manager (existing, shared cross-platform configuration)
3. Install Nix Darwin
4. Setup a Linux Builder with Nix Darwin
5. Setup a UTM VM with NixOS w/GUI
6. Install NixOS in headless VMs using Lima and https://github.com/nixos-lima
7. Have macOS VMs (generally with Nix Darwin) running under UTM for testing, etc.

And I want all of this to be as declarative and reproducible as possible. (Should be weeks of fun!)

Can anyone recommend a guide or even a blog post that presents a big-picture approach to doing this "all-of-the-above" Nix on Mac setup?

do we have a standard recommendation for how to handle meta.mainProgram/nix run compatibility for packages that produce an app bundle? I've seen:

1. symlinking the binary to $out/bin via something like ln -s $out/{Applications/${name}.app/Contents/MacOS/${name},bin/}
2. using makeBinaryWrapper to do something similar
3. putting a wrapper script in $out/bin that calls open -na on the produced application bundle

Is one of these unambiguously "better" than the others? I recall the symlink approach having issues (and I can find comments in nixpkgs and on PRs to that extent), so makeBinaryWrapper seems better than that for not a lot of overhead. I vaguely recall some cases where even that approach doesn't work (properly), and see some examples in nixpkgs (libreoffice, mongodb-compass, beekeeper-studio, jetbrains, tigervnc) using open instead, but that has some other behavioral differences (such as exiting in the terminal immediately, unless we standardize on using -W). Maybe there isn't a universal right answer, but I feel like it'd be helpful to have docs either way

In reply to @samasaur:matrix.org

do we have a standard recommendation for how to handle meta.mainProgram/nix run compatibility for packages that produce an app bundle? I've seen:

1. symlinking the binary to $out/bin via something like ln -s $out/{Applications/${name}.app/Contents/MacOS/${name},bin/}
2. using makeBinaryWrapper to do something similar
3. putting a wrapper script in $out/bin that calls open -na on the produced application bundle

Is one of these unambiguously "better" than the others? I recall the symlink approach having issues (and I can find comments in nixpkgs and on PRs to that extent), so makeBinaryWrapper seems better than that for not a lot of overhead. I vaguely recall some cases where even that approach doesn't work (properly), and see some examples in nixpkgs (libreoffice, mongodb-compass, beekeeper-studio, jetbrains, tigervnc) using open instead, but that has some other behavioral differences (such as exiting in the terminal immediately, unless we standardize on using -W). Maybe there isn't a universal right answer, but I feel like it'd be helpful to have docs either way

In reply to @benjaminsparks:chat.alugha.app
consider not setting a meta.mainProgram, then providing script aliases that point at the executables of that bundle