Should we expose the type for modular services

Development
1

Following @roberth’s call for feedback in the modular services PR (I think here is a better place to have open-ended discussion or simply asking questions):

In a project I want to say: this option holds a modular service. In order to do that, it would be nice to access the portable service module from an attribute. This would also make it slightly more convenient to build service management components – the systemd one directly imports by relative path, but external users shouldn’t have do that.

I imagine being able to do something along the lines of:

{ lib, ... }: {
  options.service = lib.mkOption {
    type = types.deferredModuleWith {
      staticModules = [ lib.nixos.types.portable-service ];
    };
  };
}

Anything that would speak against that? Except maybe that we don’t seem to have precedent for exposing entire modules for reuse as types. We don’t expose a lot of things in lib.nixos in the first place. I think portable services could warrant starting a lib.nixos.types, or at least a discussion how to expose modules that can also serve as submodule types.

Edit: I see it has become a bit more complicated than that since pkgs has been taken out of the module arguments.

Edit2: Ah scrap (most of) it, there’s the configure entry point I had overlooked on first read, which implements the type I was asking for. We can have a stare fight over names such as extraRootSpecialArgs though ಠ_ಠ. It puts the cherry on top of the classic extraSpecialArgs from Home Manager.

3 Likes