Wanted to discuss this proposal here:
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?
- 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
Does this subsume wrapper scripts?
Yes that’s the idea, unless there is a special case of course.
Nice! Thank you for tackling this problem :-).
Just one question: how does this setup work with “nested” wrappers, like the ones we get for
- firefox (
- 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.
Yes, the new makeWrapper can read the target and if it’s already wrapped, just merge the configs into a new config.
To automate that, it’s probably best to store the config as a (shortened) hash of the contents.
Those config files would just be
envvar=value\n, unless we can think of other things to put in there? Maybe niceness?
Without having read the details, this is probably relevant: Declarative wrappers