Augment or replace mkInstallModule with options in core?

[BirdeeHub]

It is possible to return a module for another module system as an option of type lib.types.deferredModule or lib.types.raw

In my config, I did this for setting utempter for tmux on nixos installs here is how I imported it and here is where I defined it

It is also possible to make a module that will detect the current module system and apply the correct arguments like so:

{ _class, ... }: {
  homeManager = {};
  nixos = {};
}.${_class}

You can also do this

{ _class, ... }: {
  imports = {
    homeManager = [];
    nixos = [];
  }.${_class};
}

We could use this to export a module that is detected by mkInstallModule and added to the imports of the module created by the option.

Doing it manually may be somewhat complex for new users, but flake parts has a modules module that may serve as a generally useful example for an interface for such a thing, so that users don't have to think about it on that level of detail. And it could produce a generic module at a specified readOnly option for import elsewhere

We could include such an option in the core module, so that it is reliable to check for presence of this adapter module or not on the wrapper module.

It would help address some boilerplate in some scenarios like this one, where you may wish to set some extra options when using zsh as a default shell, for example.

https://github.com/BirdeeHub/birdeeSystems/blob/58498857c4f9dba474c641f1adca2e035e78f9f1/common/wrappers/zsh/module.nix#L10-L17

However, adding such instructions to the repo comes with some questions and concerns.

In that case, we are setting options that we do not control ourselves and thus may need maintenance. It is also another thing for contributors to have to think about when submitting a new module (maybe that is a good thing?).

It also raises another question. Many actually.

If we make these options, would we then need mkInstallModule still? Should mkInstallModule grab that value and use it directly if it exists, and otherwise do its standard thing? Or should they extend each other? How much boilerplate should be done for the author of the wrapper module in terms of the base options of passing it to environment.systemPackages themselves? Should they maybe use mkInstallModule in order to define each module? mkInstallModule is very generic in terms of the actual option names created by the function, should these options be similarly so? Should we allow them to toggle or customize the behavior but provide some by default?

I also would REALLY rather not become reliant on such an option, and still wish to create service options by generating them in the drv, and do as much in that kind of manner as absolutely possible. But then such an option could make a module that installs it to both environment.systemPackages AND systemd.packages, for example.

Many questions, but the idea seems interesting. If anyone has any feedback or ideas about the implementation of something like this, put it here, input is welcome!

[zenoli]

In general I like the idea that wrapper-module maintainers have a way to specify nixos/hm modules which would get automatically injected to the users's nixos/hm config if they hook it up with mkInstallModule.

---

Still some confusion about some of what you wrote:

We could use this to export a module that is detected by mkInstallModule and added to the imports of the module created by the option.

So basically mkInstallModule would scan the wrapper module for any of those homeManager/nixos module options (by looking if they have type raw/deferredModule?) and add them to the imports of the generated module?

Doing it manually may be somewhat complex for new users...

You mean would be complex if mkInstallModule would not take care of it and it would be left to the user to add the modules provided as options themselves?

...but flake parts has a modules module that may serve as a generally useful example for an interface for such a thing, so that users don't have to think about it on that level of detail. And it could produce a generic module at a specified readOnly option for import elsewhere

again, are you referring to the case where users would have to hook up the modules themselves?

If we make these options, would we then need mkInstallModule still?

What would be the alternative?

[BirdeeHub]

So basically mkInstallModule would scan the wrapper module for any of those homeManager/nixos module options (by looking if they have type raw/deferredModule?) and add them to the imports of the generated module?

There would be an option in core that has the resulting module.

Something like install.module or something.

That module would be a generic module that can be loaded in any of the systems, created like the examples I showed.

You mean would be complex if mkInstallModule would not take care of it and it would be left to the user to add the modules provided as options themselves?

I meant, making the generic module that can be imported in any system to export is difficult.

This is difficult

{ _class, ... }: {
  imports = {
    homeManager = [];
    nixos = [];
  }.${_class};
}

But that creates a single module that can be imported in any of the other systems.

We want them doing

install.modules.homeManager = { config, pkgs, lib, ... }: { ???? };

And then handling making a generic module to export out of that for them.

However. We will still need mkIntallModule, because we need the current module in unimported form. So we still need them to give us the whole resulting module first.

So how much responsibility should be on mkInstallModule and how much on the wrapper module's exported module I am unsure.

What would be the alternative [to mkInstallModule]?

imports = [ inputs.nix-wrapper-modules.wrappers.idk.install.module ];

But I am not sure it is possible, at least not without a PR to update the module system to expose the original set of modules instead of just the extendModules function.

Edit:

NEVERMIND YOU CAN GET THE CURRENT LIST OF MODULES AFTER ALL

This means we do not need mkInstallModule at all.

[BirdeeHub]

so....

{ inputs, util, ... }:
{ config, ... }:
let
  installMods =
    let
      allMods = builtins.mapAttrs (_: v: v.install) config.flake.wrappers;
    in
    allMods
    // {
      default = {
        imports = builtins.attrValues allMods;
      };
    };
  file = ./wrappers.nix;
in
{
  _file = file;
  key = file;
  imports = [
    inputs.flake-parts.flakeModules.modules
    inputs.wrappers.flakeModules.wrappers
  ];
  config.flake.modules.homeManager = installMods;
  config.flake.modules.nixos = installMods;
  config.flake.modules.darwin = installMods;
  config.flake.modules.generic = installMods;
}

^ I have this working?

[BirdeeHub]

still working on it, but it lets you also do this inside a wrapper module to add stuff to the install module

      config.install.modules.nixos =
        { config, lib, ... }: let
          cfg = top.config.install.getWrapperConfig config;
        in {
          config = lib.mkMerge [
            (top.config.install.addWrapperModule {
              options.asSystemDefault = lib.mkEnableOption "zsh as defaultUserShell";
            })
            (lib.mkIf cfg.enable {
              environment.pathsToLink =[ "/share/zsh" ];
              users.defaultUserShell = lib.mkIf cfg.asSystemDefault cfg.wrapper;
              programs.zsh.enable = lib.mkIf cfg.asSystemDefault true;
            })
          ];
        };