How about making a __nixExec binary that knows about the nix store, and a shebang like #!/usr/bin/env __nixExec configName [...args] would make it search for /nix/store/package-where-real-scriptfile-is/.nixExec-configName to set the path and so on, and it also reads the first line of the script to get all the arguments so we’re not limited to the 128 chars of Linux?
Then
shebang points to an executable so it works on Darwin
we have unlimited arguments
it will properly fail if __nixExec doesn’t exist
__nixExec can do extra checks at runtime if needed, complaining about missing packages with the nix-store command to run etc
script content will stay mostly unchanged between versions and give slightly better deduplication rates
Just one question: how does this setup work with “nested” wrappers, like the ones we get for
firefox (${firefox}/bin/firefox → ${firefox-unwrapped}/bin/firefox → ${firefox-unwrapped}/bin/.firefox-wrapped), or
when improperly using wrapGAppsHook on top of a custom wrapper (see calibre for example, where gappsWrapperArgs should be preferred), or
more generally when calling wrapProgram multiple times, as explicitly supported in make-wrapper.nix ?
Can this tooling be used to flatten the wrappers stack somehow ? Does it come with a change in nixpkgs makeWrapper interface ?
It is okay to split the change in two parts, but the interface should be designed beforehand.