Producer quirks taking pkgs argument

[Adda0]

Heya. Finally checking out the new architecture of Den and quirks got me curious. Reading about den.quirks, it seems like a good feature for what I wanted to do for a while (sharing arbitrary Nix values between aspects with conditional filtering, etc.), but possibly not sufficient (ergonomic for my use case) as they are now, I think.

Let us say I want to define shell command abbreviations across multiple aspects (aspect nix: n for nix; git: g for git; just: j for just, ...), e.g.:

den.quirks.abbreviations = {
  description = "Abbreviations";
};
# These are the problematic arguments.
den.aspects.git.abbreviations = { lib, pkgs, ...}: {
  abbreviations = {
    g = "${lib.getExe pkgs.git}";
  };
};
den.aspects.just.abbreviations = { lib, pkgs, ...}: {
  abbreviations = {
    j = "${lib.getExe pkgs.just}";
  };
};
den.aspects.fish.homeManager = { lib, abbreviations, ... }: {
  programs.fish.shellAbbrs = lib.mergeAttrsList abbreviations;
};

The issue is that the quirks need both lib and pkgs. How to ergonomically pass pkgs and other arguments besides the lib argument to quirks? Is that even a desirable approach to using quirks? One could make the quirks contain lambdas pkgs: { j = "just"; }, and pass pkgs to each item in the list abbreviations upon consumption, but that is not ergonomic, as that would require the user to do this for every place the quirk is consumed. And I think policies are not good either, since they operate on a different context level (the aspect context level, not the nixos, homeManager, ... level). I may be overlooking something obvious. Or is there a better approach to this problem, maybe even one that doesn't rely on quirks?

[dnlzro]

I think this is an example of what you're trying to do: https://den.denful.dev/explanation/fleet/#config-dependent-cross-host-data

[Adda0]

I do not believe so. Yeah, I want to use it like this, but I also need pkgs in the argument attrset. config, host, or lib do not contain pkgs.

[fmway]

I'm not familiar with quirks, but your case can be resolved using custom class (+ forwarder)

Here an example:

{ den, lib, ... }: let
  abbrFwd =
    { class, aspect-chain }:
    den.batteries.forward {
      each = [ "nixos" "homeManager" ]; # remove nixos if you only want to forward to homeManager
      fromClass = _: "abbreviations";
      intoClass = lib.id;
      intoPath = _: [ "programs" "fish" "shellAbbrs" ];
      fromAspect = _: lib.head aspect-chain;
      guard = { config, ... }: _: lib.mkIf config.programs.fish.enable;
    };
in {
  # Register `abbreviations` class into global classes
  den.classes.abbreviations = {};

  # Import the forwarder to all entities
  den.default.includes = [ abbrFwd ];
}

Then, you can use it like your previous config (without duplicating abbreviations key)

den.aspects.git.abbreviations = { lib, pkgs, ...}: {
  ls = "${lib.getExe pkgs.git}";
};
den.aspects.just.abbreviations = { lib, pkgs, ...}: {
  j = "${lib.getExe pkgs.just}";
};

You don't need to manually collect them in the fish aspect. The forwarder will collect them for you, and you just need to enable fish so that the abbrs are available and usable (look at the guard, remove it if you want to expose abbrs even when fish is disabled)

[Adda0]

Thanks for the detailed reply ❤️ While one can certainly do this (and I now do as well), it amounts to manually reimplementing the quirks feature, as it is my understanding that quirks are meant to be an ergonomic (easy-to-use) implementation of this, basically, used to share structured data across aspects. I think the need to construct the shared data using functions from pkgs is a valid one, most notably passing around derivations, etc. So, I will keep this discussion open for now to see what people think. Talking strictly about my use case, forwarded custom classes are definitely a possible solution.

[fmway]

Sorry, it's a long time, you may have already found a solution. We can pass the args in the collector aspect.

e.g:

den.quirks.abbreviations = {
  description = "Abbreviations";
};
# These are the problematic arguments.
den.aspects.git.abbreviations = { lib, pkgs, ...}: {
  g = "${lib.getExe pkgs.git}";
};
den.aspects.just.abbreviations = { lib, pkgs, ...}: {
  j = "${lib.getExe pkgs.just}";
};
den.aspects.fish.homeManager = { lib, config, pkgs, abbreviations, ... }: let
  args = config._module.args // config._module.specialArgs // { inherit lib config pkgs; };
  fix = item:
    if item ? __fn && builtins.isFunction item.__fn then
      item.__fn (builtins.intersectAttrs (builtins.functionArgs item.__fn) args)
    else item;
in {
  programs.fish.shellAbbrs = lib.mergeAttrsList (map fix abbreviations);
};

[fmway]

Also, we can force the pipe not to use the host config when the pipe detects a config param. This can be resolved by using pipe.for lib.id. Then we can combine with pipe.withProvenance to retrieve the args from the aspect-related (host, user, home, etc).

The final result looks like this:

{ den, lib, ... }: let
  inherit (den.lib.policy) pipe;
in {
  den.quirks.abbreviations = {
    description = "Abbreviations";
  };
  den.schema.user.includes = [
    den.policies.abbreviations-to-user
  ];
  den.policies.abbreviations-to-user =
    { host, user, ... }:
    pipe.from "abbreviations" [
      (pipe.for lib.id)
      pipe.withProvenance
    ];
  # These are the problematic arguments.
  den.aspects.git.abbreviations = { lib, pkgs, ...}: {
    g = "${lib.getExe pkgs.git}";
  };
  den.aspects.just.abbreviations = { lib, pkgs, ...}: {
    j = "${lib.getExe pkgs.just}";
  };
  den.aspects.fish.homeManager = { lib, config, pkgs, abbreviations, ... }: let
    args = config._module.args // config._module.specialArgs // { inherit lib config pkgs; };
    fix = item:
      if item.value ? __fn && builtins.isFunction item.value.__fn then let
        fargs = builtins.functionArgs item.value.__fn;
        args' = item.source // args;
      in
        item.value.__fn (builtins.intersectAttrs fargs args')
      else item.value;
  in {
    programs.fish.shellAbbrs = lib.mergeAttrsList (map fix abbreviations);
  };
}

[fmway]

I'm using intersectAttrs to remove unnecessary args. You can just use __fn args' instead.

[Adda0]

Heya. I think this is precisely what I wanted to achieve. Thank you kindly ❤️ Marking as resolved with this.

Nevertheless, I would maybe expect Den to do this automatically for quirks specifically, to make them easier to work with. Maybe an idea for a future FR...

[fmway]

Nevertheless, I would maybe expect Den to do this automatically for quirks specifically, to make them easier to work with

Idk, but that seems like a complicated task, since it involves a specific class. Meanwhile, quirks can be collected by any class.

[fmway]

Good news @Adda0! #625 allow quirks/pipe to pass module args. Will be merged soon.

[Adda0]

I just saw this mentioned in the Matrix chat. That is precisely what I envisioned. Gives me what I need and is exactly as simple to use as I wanted it to be. What I also like about quirks is that one processes the collected data precisely where one would expect to find it (in the target program configuration). Manually creating the forwarders or implementing additional harnesses around the data felt too cumbersome to use too frequently for every small piece of data. Now, there is no additional churn. Awesome ❤️

[sini]

Technically quirks are processed in the producing class... I have a minor fix open with #633 where home-manager sourced quirks weren't properly getting exposed. 625+633 are probably the last contributions to the current effects based den before I ship the full rewrite with den-hoag on gen.