Making wrapper scripts that do something other than exec?

[musjj]

Something like this:

wrapPackage {
  inherit pkgs;
  package = pkgs.cowsay;
  wrapperScript = ''
    "$EXE_PATH" "$@" >"$XDG_DATA_HOME/cowsay/cowsay.log"
  '';
}

This will move the original binary to something like bin/.cowsay-wrapped, then drop your wrapper script to bin/cosway. The wrapper script is also injected with an environment variable (e.g. $EXE_PATH) that refers to the absolute path of the original binary.

[BirdeeHub]

wrapPackage ({ config, ... }: {
  inherit pkgs;
  package = pkgs.cowsay;
  env.EXE_PATH = "${config.wrapperPaths.input}";
})

I suppose I am a little confused.

This whole library IS the options for generating wrapper scripts.

Could you explain how this would be different/what is it for?

[musjj]

It's for something a bit more custom. It's similar to runShell, but for customizing how the main program is actually run.

For example, you might want to run the main program inside boxxy: boxxy cowsay. Or running it inside a sandboxed bubblewrap. It can also be useful for redirecting the outputs to specific paths like I've illustrated above.

Of course you can orchestrate this manually, but a built-in option would be nice.

[BirdeeHub]

The wrapperImplementation = "nix" backend allows you to pass a function to argv0type https://birdeehub.github.io/nix-wrapper-modules/modules/makeWrapper.html#argv0type

That allows you to customize the way it gets ran as you suggest

---

Unfortunately, the other wrapper backends do not have this capability, as they are constructed via pkgs.makeWrapper and pkgs.makeBinaryWrapper so we do not have as direct control over their operation.

You could enforce that something uses only the default backend though, as you can exclude the wrapperImplementation option on import of the makeWrapper module, and then redefine it to be whatever you want, i.e. a readOnly option containing "nix" to force use of the default backend which does have this capability.

If you have to use one of the other backends for the makeWrapper options (for example, you would need the binary one if it is something mac users would want to put in a shebang), you may wish to do

config.buildCommand.preMakeWrapper = {
  before = [ "makeWrapper" ];
  after = [ "constructFiles" ];
  data = ''
    mv ${config.wrapperPaths.input} ${placeholder config.outputName}${config.wrapperPaths.relDir}/.${config.binName}
    echo "#!${pkgs.bash}/bin/bash" > ${config.wrapperPaths.input}
    echo "${pkgs.boxxy}/bin/boxxy ${placeholder config.outputName}${config.wrapperPaths.relDir}/.${config.binName}" >> ${config.wrapperPaths.input}
  '';
};

(or the other way around, put it after makeWrapper and move the final wrapper and wrap it again)

We could maybe make a way to do this for the user, to make argv0type accept a function in any of the backends rather than just the nix one, but there would still be some differences in behavior between them, hence why I did not do that yet.

It is probably worth trying to find a way to standardize that capability better.

But if we made a helper module for bubblewrap, we could simply make it take the result of whatever wrapper it is, and move it to .thatname and then wrap it with bubblewrap. We would do it that way to avoid conflicts with stuff, and keep it a separate thing you can import if needed without having an impact or dependence on the other helper modules

So, it is not a thing we would use for bubblewrap wrappers necessarily? But for things that wouldnt have its own helper module it would be a useful capability to have that slightly standardized across the different wrapper implementations somehow as well?

The other thing is, you can completely redefine the wrapper function. So, it is always possible to fall back on that, and there are functions in the repo for helping you do that easier and still accept the same options. So in that way, you could construct basically whatever kind of wrapper you wanted via the same options normally offered by the makeWrapper module as well.

[BirdeeHub]

Since this is already technically addressed by the features of the repo, and is only so possible to address better, and the goal is to have better support for this if possible, but I am not sure how possible better support is, I am thinking I might move this to a discussion?