Activating a class module on an aspect depending on condition

[AnonymousRand]

Is there a clean way to activate a particular class module on an aspect depending on if some condition is met? For example, currently each of my hosts declare the capabilities it provides (e.g. networking, battery, graphics), and feature aspects check that the capabilities they provide are provided by the host within the current resolution in order to selectively activate their class modules:

# features/ghostty.nix
# included by user `alice`'s aspect,
# but should only take effect on hosts with graphics
{
  den.aspects.features.ghostty = {
    homeManager = { host, ... }:
    import ../_require_capabilities.nix host [ "graphics" ] {
      programs.ghostty.enable = true;
    };
  };
}

# _require_capabilities.nix
host:
requiredCapabilities:
output:
let
  areRequiredCapabilitiesMet = ...; # check if required capabilities satisfied on host
in
if areRequiredCapabilitiesMet then
  output
else
  {}

Ideally, I would like to refactor _require_capabilities.nix such that I don't have to reference it by relative path everywhere. For example, maybe turn it into an aspect which upon inclusion into a feature aspect would automatically adjust that feature's class modules as needed. However, I'm not sure if I can get this to work without doing something very messy like passing the feature aspect itself into the require-capabilities aspect (in order to only target that feature's class modules and not the final merged ones with config.homeManager and the like).

Is there a cleaner way to do this? And maybe turning it into an aspect isn't the right move? (And I know using custom classes as roles is one way to provide similar-ish "capability" functionality, but I don't want to have to keep track of so many new class names with a whole bunch of roles/capabilities. Also, that is limited to one class at a time.)

[fmway]

I've an idea. How about this?

{ den, lib, ... }: let
  # deps host.hasCapability & host.capabilities
  capabilityOpts =
    { lib, host, ... }:
    {
      options = {
        hasCapability = lib.mkOption {
          type = with lib.types; functionTo bool;
          readOnly = true;
          default = capability:
            builtins.elem capability host.capabilities;
        };
        capabilities = lib.mkOption {
          type = with lib.types; listOf str;
          default = [];
        };
      };
    };
in {
  den.schema.host.imports = [ capabilityOpts ];

  den.hosts.x86_64-linux = {
    igloo.capabilites = [ "graphics" ];
    iceberg = {};
  };

  den.aspects.features.ghostty = {
    homeManager =
      { host, ... }:
      lib.optionalAttrs (host.hasCapability "graphics") {
        programs.ghostty.enable = true;
        # ....
      };
  };

  # ....
}

You might want to refactor hasCapability (string) into hasCapabilities (list of strings)

[drupol]

This should be in the documentation!

[AnonymousRand]

Agreed, could be a useful example to have!

(Although I guess a natural follow-up is to ask if this can also be done for standalone homes so that feature aspects, specifically their home modules, can check the capability on either host or home without needing both to exist in the context simultaneously. In other words, the feature works whether it is included as part of a standalone home configuration or a nixos configuration...that's a problem for a later day lol)

[fmway]

Use parametric { home ? null, host ? null }. That makes both optional. Like, when not in standalone hm, home = null.

I'm not sure about your use case, but it might be worth a try.

[AnonymousRand]

Aha! I think this is what I was looking for, thank you. (My use case is that I want standalone homes to also be able to install ghostty, for example, as opposed to the current thing I have which only checks a host's capabilities.)

[fmway]

My use case is that I want standalone homes to also be able to install ghostty, for example, as opposed to the current thing I have which only checks a host's capabilities.

Yeah, It should work.