Wrap selected binaries or all of them

[musjj]

Some packages don't have a main binary (e.g. mainProgram), for example: https://github.com/NixOS/nixpkgs/blob/nixos-25.11/pkgs/by-name/hy/hydrus/package.nix#L161

Currently, wrapPackage will generate a wrapper called bin/hydrus which will execute a non-existent binary. It would be nice if there's an option to choose which binary gets wrapped (or just automatically wrap all of them).

[musjj]

Looks like this is the intended way to use it:

inputs.wrappers.lib.wrapPackage {
  inherit pkgs;
  package = pkgs.cowsay;
  wrapperVariants.foobar = { };
  wrapperFunction =
    {
      config,
      wlib,
      callPackage,
      ...
    }:
    (import wlib.modules.makeWrapper).wrapVariants {
      inherit config wlib callPackage;
    };
}

It feels very verbose though, it would be nice if there's a simpler approach.

Also even with this method, there's no option to autowrap all the binaries in /bin/*, so you need to specify each binary name manually.

[BirdeeHub]

I mean, what you did works technically, but it feels overcomplicated.

Also you redefined it in a more verbose way than necessary (Edit: turns out you did not, but this less verbose way works now), this is equivalent to your cowsay example

inputs.wrappers.lib.wrapPackage {
  inherit pkgs;
  package = pkgs.cowsay;
  wrapperVariants.foobar = { };
  wrapperFunction = (import wlib.modules.makeWrapper).wrapVariants;
}

It takes the same arguments and returns a string, so you can just use that directly.

The value from calling it is given to builderFunction.

Verbosity aside though, can't this be fixed by setting binName or exePath to something else for either the main binary or one of the variants?

I don't understand the cowsay example. What is it trying to create?

Cowsay does not contain a foobar binary and if it did and you did want to wrap that and not cowsay, you would just set binName = "foobar"; and exePath = "bin/foobar";

exePath is what we are wrapping, binName is the name of the output binary.

The variants by default have the same values you set in the main wrapper options but can be modified, except they have exePath and binName set to something else by default.

If you want to change the meta.mainProgram value only, by default it will be binName, but you can do drv.meta.mainProgram and set that directly too.

There is no "wrap all of them", there are not very many derivations where it contains enough things in bin/ for that to be a problem. And if you were wrapping them all the same way, that would just be 1 line per binary using the wrapperVariants option. Theoretically this is possible, however there would be no way to get information about that back into nix, only within the drv's build script, as otherwise that is IFD. So such an option would likely have to be mutually exclusive with the wrapperVariants options, or you would have to accept much more hidden behavior.

wrapperVariants is for wrapping many packages the same way, or 1 package many ways, depending on how you set exePath and such for each variant. However if you are wrapping only 1 binary in 1 way, you should not need it.

However what you provided is far more verbose than it should be, and redefining wrapperFunction should not be necessary here.

[BirdeeHub]

inputs.wrappers.lib.wrapPackage {
  inherit pkgs;
  package = pkgs.cowsay;
  exePath = "bin/foobar";
  binName = "foobar";
}

if cowsay had a bin/foobar and you wanted to wrap that and NOT bin/cowsay, which it appears is what your example is doing, you would just do this.

Is that what the goal is here?

i.e.

inputs.wrappers.lib.wrapPackage {
  inherit pkgs;
  package = pkgs.hydrus;
  # you should pick whichever one you would run via `nix run` for the main one.
  exePath = "bin/hydrus-client";
  binName = "hydrus-client";
  # wrap the package
  
  # will repeat whatever you set for the main one but with different `exePath` and `binName` unless you change some values per item.
  wrapperVariants.hydrus-server = {};
  wrapperVariants.hydrus-test = {};
}

Does that achieve the goal you wanted to achieve?

If you really really wanted them all to have entirely disconnected options, that would be when you would do the verbose thing, but I am pretty sure this would be quite rare

inputs.wrappers.lib.wrapPackage {
  inherit pkgs;
  package = pkgs.hydrus;

  # redefine wrapperFunction so that it doesn't wrap a main one (this is equivalent to what you had for cowsay)
  wrapperFunction = (import wlib.modules.makeWrapper).wrapVariants;
  # top level exePath now does nothing, and binName is used a few places, but the only one of note here is:
  drv.meta.mainProgram = null; # <- I am pretty sure setting null for meta.mainProgram is OK? If not choose one and we can maybe see about what to do about that, but honestly we probably should choose one anyway for hydrus.

  # now they will all inherit from what you set at the top level, but there is no "main" one.
  wrapperVariants.hydrus-client = {};
  wrapperVariants.hydrus-server = {};
  wrapperVariants.hydrus-test = {};

}

I don't expect this to be common though, usually the first way is the way to go? It is usually only 1 or 2 options which need to differ for the variants if any, so usually I would say you should just set those for the variants yourself in your module instead of redefining wrapperFunction.

The fact you CAN do that is good, and given the amount of behavior the above example redefines, it is honestly pretty decent in terms of verbosity? But I am not sure it is what you need here to achieve what you want, basically. Totally fine if it is the best thing to do, but it is at least not the only way to do it.

[musjj]

Thank you, I didn't know that binName works on the top-level. The documentation only mentions it as nested inside wrapperVariants. Yeah, this is good enough for me.

Note that this does not work for me though:

inputs.wrappers.lib.wrapPackage {
  inherit pkgs;
  package = pkgs.cowsay;
  wrapperVariants.foobar = { };
  wrapperFunction = (import inputs.wrappers.lib.modules.makeWrapper).wrapVariants;
}

It errors with:

       error: function 'wrapVariants' called with unexpected argument 'name'
       at /nix/store/5m8gisfdln2v1cvf9jb3i569s3ma8s2l-source/modules/makeWrapper/module.nix:555:5:
          554|   wrapVariants =
          555|     {
             |     ^
          556|       pkgs ? null,

[BirdeeHub]

Oh!

I could make that work I guess....

Thanks for letting me know.

I thought that would work, and did not actually run it to check... my bad....

I can fix that pretty easily actually, may be a lot nicer.

  wrapAll =
    {
      pkgs ? null,
      wlib,
      callPackage ? pkgs.callPackage or (usage_err "wrapAll"),
      config,
      ...
    }:
    callPackage (import ./. null) { inherit config wlib; };
  wrapMain =
    {
      pkgs ? null,
      wlib,
      callPackage ? pkgs.callPackage or (usage_err "wrapMain"),
      config,
      ...
    }:
    callPackage (import ./. false) { inherit config wlib; };
  wrapVariants =
    {
      pkgs ? null,
      wlib,
      callPackage ? pkgs.callPackage or (usage_err "wrapVariants"),
      config,
      ...
    }:
    callPackage (import ./. true) { inherit config wlib; };

If I add the ... it will work

Im not going to do it for wrapVariant though, because it doesn't make sense to use wrapVariant in this way.

also binName docs should be defined in the core options and exePath should as well

[BirdeeHub]

ok, now the shorter version where you just pass it directly should work haha my bad sorry

If you want to do it that way, go for it, otherwise, yeah, binName and exePath work at top level as well they just are not defined by the makeWrapper module but core instead.

binName is used for pname and a few other things if the drv used doesn't provide one, so it had to be in core, and I did not really know what to do with exePath but it seemed a good idea for wrapperFunction implementations to use such an option so I added it there as well so that if people do their own wrapperFunction implementations they will use the already existing exePath option

And then the variants are literally the same exact function just called on the value from one of the wrapperVariants instead of the whole config

[musjj]

Thanks!

they just are not defined by the makeWrapper module but core instead.

Oh my bad, I see it now.

[BirdeeHub]

Also related, the reason wrapperVariants was added in the first place:

#233

[BirdeeHub]

#311

When this PR is merged, this discussion will be closed as (import wlib.modules.makeWrapper).wrapVariants and the like have been moved to wlib.makeWrapper, and importing the module like that is only for excluding options and stuff that actually modify the module

The functions that have been moved have been given deprecation warnings in the PR

[musjj]

To clarify, once the PR is merged the following:

inputs.wrappers.lib.wrapPackage {
  inherit pkgs;
  package = pkgs.cowsay;
  wrapperVariants.foobar = { };
  wrapperFunction = inputs.wrappers.lib.makeWrapper.wrapVariants;
}

Will only wrap bin/foobar, right?

[BirdeeHub]

yes it has been renamed and you no longer need to pass wlib to it, and you can also pass wrapperImplementation to it, but otherwise it is the same.

[BirdeeHub]

I basically just moved them, but I also added 3 more helper functions, (and used them)

[BirdeeHub]

I now also actually use wlib.makeWrapper.wrapAll as the actual one used by the makeWrapperModule, so it is now tested that it works when used directly (and hopefully I will find the time to add more tests for that stuff XD)