Extending Types(Not the usage of them) in NixOS Modules: Is it Possible?

Help
1

Is there a way to extend the submodule type itself in a NixOS module?

For example, consider the following scenario:

# module1.nix
let
  t1 = types.submodule {
    options = {
      bar = mkOption {
        type = types.int;
        default = 1;
      };
    };
  };
in
{ foo = mkOption { type = t1; }; };
# module2.nix
let
  t2 = types.submodule ({ name, config, ... }: {
    options = {
      # This represents t2
      baz = mkOption {
        type = types.bool;
        default = true;
      };
    };
  });
in
{ foo = mkOption { type = t2; }; };

This approach results in the type of foo becoming a merged submodule with both bar and baz options. However, I want to extend the submodule type t1 itself, rather than just merging the options.
Why do I want to do this? I’m trying to create a reusable options to kubenix which contains a set of kubenertes resource corresponding types as submodules.
However, I can’t extend, for example, Pod by addding a new option gpu-enabled without modifying the Pod type definition itself. I wonder if I can extend rather than modify the original type definition.

What I’m aiming for is something like this:

# We don't have such a thing as typeDefs, but let's assume we do.
# module1.nix
typeDefs.fooType = types.submodule {
  options = {
    bar = mkOption { type = types.int; };
  };
}

# module2.nix
typeDefs.fooType = types.submodule {
  options = {
    baz = mkOption { type = types.bool; };
  };
}

{ cfg, types }: {
  options = {
    foo = mkOption { type = types.fooType; } # fooType = merged submodule with bar and baz
  };
}

However, as far as I know, types in NixOS modules are just structural and anonymous values (without any global path), so this seems impossible. It appears that referring to the submodule type that I want to extend is not possible.

Is there a way to achieve this kind of type extension?

Alternatively, I’m thinking of creating a meta NixOS module that outputs a type, evaluating it, and then inserting the resulting model back into the module. Has there been any attempt at this kind of approach?

2

Adding the original module to disabledModules and then creating a new module with the necessary modifications seems like the most straightforward method I can think of.

3

Sorry I didn’t provide the context enough. I was trying kubenix and it has various custom option types each corresponding to kubenertes resource(pod, container, etc). I want to extend the definition so that I can introduce my own custom options to manipulate configuration, which is rendered to YAML.

4

As container type can be referred from many different locations, for example, under pods, and deployments, I want to avoid extending container typed option for each usage. I’m looking for a way to directly put more nested options under container type.

5

Your example is confusing because you state that the upper example becomes t1 + t2 while the desired state …also becomes t1 + t2? Doesn’t that mean the status quo and the desired state are one and the same?

You should also explain what you mean by + here and in what way do you want to “extend” the type.

6

+ means merging of submodules. Sorry about the vague description.
I restated my question with a concrete example.

7

Oh this was a massive x-y.
You can either use attrsOf submodule (which is I assume what you want since I’d assume you can have multiple “pods” with the same structure?) or look into the more complex incantations in Submodule types.

To see examples of the former in action:

(of course you can check out the local bindings in the respective files to see what they contain, but this should demonstrate the idea)

8

I created a project GitHub - bglgwyng/nix-meta-module. The examples in the repository should help better illustrate the concept and its use cases.