wrapper-manager icon indicating copy to clipboard operation
wrapper-manager copied to clipboard

One module eval per wrapper

Open viperML opened this issue 1 year ago • 3 comments

Thinking about the current implementation of wrapper-manager, maybe it is better to have one lib.evalModules per wrapper, instead of a single one (like the current implementation).

The problems it would solve:

  • ~~Threading one wrapper to another (for example, wrapper B includes A, which is also a wrapper)~~ This can be done with config., nevermind
  • Easily create wrappers for one-off things, like programs.<name>.package options from NixOS.

What it could make easier:

  • Integration with the splicing of nixpkgs (to allow for cross-compilation etc) (But perhaps can be done with the current impl)

As for the negatives:

  • Maybe a negative performance impact, in cpu cycles or memory (to be measured)

viperML avatar Mar 07 '24 07:03 viperML

I think the best way is to have the current API as is but also provide a convenience function which evals a single wrapper type and returns the wrapped package

nrabulinski avatar Mar 07 '24 07:03 nrabulinski

So a more convenient way of doing this?

(wrapper-manager.lib {
    inherit pkgs;
    modules = [
        {
            wrappers.hello = {
                basePackage = pkgs.hello;
                flags = ["--help"];
            };
        }
    ];
}).config.wrappers.hello.wrapped

Or am I misunderstanding this?

SebastianStork avatar May 07 '24 10:05 SebastianStork

yes

viperML avatar May 07 '24 15:05 viperML