Is it possible to use wrapper modules with macOS app bundles?

[emonadeo]

I am trying to use wrapper modules on darwin/macOS, and for anything launched from the terminal it works without problems, since executables in PATH point to the wrapped launch script at e.g. $out/bin/ghostty. However on darwin non-terminal apps are bundled with a secondary binary located at $out/Applications/Ghostty.app/Contents/MacOS/ghostty, which does not get patched/wrapped when using nix-wrapper-modules.

As such when running one of these apps from Spotlight (macOS' app launcher), the wrapped binary is not run and therefore flags and configurations not applied.

Is it possible to wrap these as well? So far I haven't been successful in my attempts, but I'd love to see nix-wrapper-modules support this.

Perhaps relevant prior art:
https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/by-name/mp/mpv/package.nix, which seems to create wrappers for these exes on darwin.

[BirdeeHub]

So, yes. But I didn't know about it before yesterday, as I was reviewing exactly the derivation you linked.

It seems most nix derivations don't offer this?

you would basically have to wrap it separately, or link it there.

Is it the exact same binary always?

If so, it might be easiest just to link it there, if mac allows that value to be a link? Or copy it?

buildCommand.macAppBundle = ''
  mkdir -p ${config.outputName}/Applications/Ghostty.app/Contents/MacOS
  ln -s ${config.wrapperPaths.placeholder} ${config.outputName}/Applications/Ghostty.app/Contents/MacOS/ghostty
'';

If not, then wrapperVariants will repeat the wrapper instructions for some other binary

wrapperVariants.ghostty = {
  exePath = "Applications/Ghostty.app/Contents/MacOS/ghostty";
  binDir = "Applications/Ghostty.app/Contents/MacOS";
};

It is possible that mac needs it to not only be not a link, but also a binary rather than a script.

If so,

wrapperVariants.ghostty = {
  exePath = "Applications/Ghostty.app/Contents/MacOS/ghostty";
  binDir = "Applications/Ghostty.app/Contents/MacOS";
  wrapperImplementation = "binary";
};

And if it didnt already have one present, and you wanted to make one, you can either copy it there just like above, or you could do the wrapperVariants thing, but you would set exePath to be pointing just at "bin/${config.binName}" so that it wraps the same thing again, but to the new place (although actually, in this case, I did wrapperVariants.${config.binName}, so you actuallly wouldnt have to set exePath either)

[emonadeo]

Tysm for the quick and elaborate response!

macOS does need it to be a binary, and works pretty well with your 3rd suggestion.
Just had to make one small adjustment.

Does not work: (Wrapped exe variant is still a bash script)

{
  wrapperVariants.ghostty = {
    exePath = "Applications/Ghostty.app/Contents/MacOS/ghostty";
    binDir = "Applications/Ghostty.app/Contents/MacOS";
    wrapperImplementation = "binary";
  };
}

Works: (But /bin/ghostty is also a binary then)

{
  wrapperImplementation = "binary";
  wrapperVariants.ghostty = {
    exePath = "Applications/Ghostty.app/Contents/MacOS/ghostty";
    binDir = "Applications/Ghostty.app/Contents/MacOS";
  };
}

Is this a potential bug?
(FYI see full wrapper module here)

[BirdeeHub]

Ok. So, this bug should be fixed after I merge my fix in #413

When investigating your config, I noticed you have flake.wrapperModules in your flake-parts modules.

https://birdeehub.github.io/nix-wrapper-modules/md/getting-started.html#flake-parts

^ we already have a flake-parts module you can use, which will take care of wrappers wrapperModules and packages outputs for the wrapper modules, you just import it and use flake.wrappers.name like a submodule, and it will handle the rest. You can specify not to build some of them as packages if you want.

You will need to have imports = [ wlib.modules.default ]; or imports = [ wlib.wrapperModules.progname ]; in said submodules to either use those options to wrap something yourself, or pick what you are wrapping

[BirdeeHub]

Also, I reopened the discussion because closed discussions are hard to find and this is definitely something that seems like it should be in an FAQ, especially until we make sure the existing modules all do this where applicable.

[BirdeeHub]

Also...

      env.FONTCONFIG_FILE = lib.mkIf pkgs.stdenv.hostPlatform.isLinux (
        pkgs.makeFontsConf { fontDirectories = [ font.package ]; }
      };

I did not know you could do this actually. This might make me try ghostty? Once they fix the bug blocking the ghostty module?

[emonadeo]

I did not know you could do this actually.

Sadly only on Linux though, since on macOS Ghostty pulls fonts from FontBook and to my knowledge fonts must always be in /Library/Fonts or ~/Library/Fonts for them to be registered. 😕

Once they fix the bug blocking the ghostty module?

You mean the bug where ghostty +actions do not work when adding other flags? That one really stumped me until I figured out it's a problem with ghostty and not the wrapper module. (Keeping my eye on #393 for this)

[BirdeeHub]

You mean the bug where ghostty +actions do not work when adding other flags?

yeah that one. The one from the PR yeah

Sadly only on Linux though

yeah... Honestly I was very upset when ghostty came out and didnt have an option for the actual font files. I was all excited to try it out, and all the excitement immediately evaporated and I stayed on wezterm.

I want 2.5 terminal features in a terminal

I want kitty support, absolute path to fonts dir/files, and some very basic keybinds, mostly just ctrl+shift+v

everything else i do via tmux. Maybe zellij someday but tmux is fine.

Ghostty lets me turn off all the features I don't care about, but it doesnt have that 1 feature of specify absolute path to font

[karldelandsheere]

Thanks so much you both for this discussion. I learned a lot.

Does it install Ghostty under Applications/Nix Apps/Ghostty.app for you too? Not a problem but I provided Applications/Ghostty.app so I don't know if it just ignored it or not.

Cheers!