| 21 Feb 2026 |
|  h7x4 changed their profile picture. | 19:27:17 |
| h7x4 changed their profile picture. | 19:30:39 |
| h7x4 changed their profile picture. | 19:34:04 |
| 22 Feb 2026 |
|  Cedar joined the room. | 02:54:07 |
|  Desdaemon joined the room. | 04:14:32 |
| 23 Feb 2026 |
|  @philip4g:matrix.org left the room. | 06:16:26 |
 samasaur | 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:
- symlinking the binary to
$out/bin via something like ln -s $out/{Applications/${name}.app/Contents/MacOS/${name},bin/}
- using
makeBinaryWrapper to do something similar
- 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
| 06:29:38 |
 rebmit[reb] | 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:
- symlinking the binary to
$out/bin via something like ln -s $out/{Applications/${name}.app/Contents/MacOS/${name},bin/}
- using
makeBinaryWrapper to do something similar
- 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
an example of symlink causing behavior differences I ran into recently: https://github.com/NixOS/nixpkgs/pull/489364 | 06:55:25 |
| samasaur | yea that's what prompted me to ask, i have the zotero, cinny, and nheko PRs up in tabs rn | 06:56:06 |
 toonn | Each of those approaches has more overhead than the last is worth mentioning. | 08:25:20 |
| toonn | Maybe also the fact that them not working might be of interest to upstream. | 08:26:27 |
 Ben Sparks | consider not setting a meta.mainProgram, then providing script aliases that point at the executables of that bundle | 11:22:13 |
| Ben Sparks | let multiOutputBundle = stdenv.mkDerivation { ... }; let singleProg = writers.makeShellScript { "${multiOutputBundle}/bin/$MY-SINGLE-PROGRAM $@" } | 11:23:52 |
| Ben Sparks | something like this perhaps? | 11:23:57 |
| rebmit[reb] | 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 i don't get it, your example seems pretty similar to using a (shell) wrapper | 11:35:44 |
| Ben Sparks | except that you don't rebuild the multiOutputBundle when you use overrideAttrs to make a new meta.mainProgram for each program | 11:36:25 |
| Ben Sparks | ahh im sorry i have misread the message 😄 is what I have written even helpful to you, probably not 😂 | 11:37:33 |
|  Michael set a profile picture. | 14:34:01 |
 WeetHet | I think the last option forces macl to be set and then nix-collect-garbage would fail | 17:49:49 |
 emily | does meta.mainProgram = "../Applications/…"; work | 17:51:50 |
| WeetHet | I think it should, it would with my nix-run | 17:54:00 |
| emily | it's kind of awful and shouldn't work | 17:57:08 |
| emily | but if it does… | 17:57:09 |
| emily | meta.mainProgram = "../../../../usr/bin/hello"; | 17:57:35 |
| WeetHet | nix --extra-experimental-features "nix-command flakes" run --impure -E "((import <nixpkgs> {}).hello).overrideAttrs { doInstallCheck = false; meta.mainProgram = \"../../../../usr/bin/true\"; }"
❮ echo $status
0
| 18:34:58 |
| WeetHet | * ❮ nix --extra-experimental-features "nix-command flakes" run --impure -E "((import <nixpkgs> {}).hello).overrideAttrs { doInstallCheck = false; meta.mainProgram = \"../../../../usr/bin/true\"; }"
❮ echo $status
0
| 18:35:03 |
|  @magpi:matrix.org changed their display name from magpi to Luke Worth. | 21:17:05 |
| @magpi:matrix.org changed their display name from Luke Worth to Luke. | 21:17:36 |
 msgilligan | I didn't get any responses and also did some searching and didn't find quite what I'm looking for. So I created a repo (with just a README) explaining what I'm trying to do and as a starting point for pulling things together:
https://github.com/msgilligan/max-nix-on-macos | 23:20:12 |
| 24 Feb 2026 |
 Ihar Hrachyshka | @msgilligan:matrix.org: FWIW 5 and 6 can be covered by native nixpkgs qemu based VMs, unless you really care it's Lima / Apple vz. | 13:06:51 |
