Importing option types from other modules

Help
1

Hi, I keep running into this scenario and wonder what the best way of handling it is.

Say, for example, I would like to write a service module. This will of course use systemd.services to actually create my service.

Now, I would like this service to be backed with a timer, which means I would like to set systemd.services.<service>.startAt. I don’t know my user’s use case, so I’d like to make this configurable.

I can just create a new downstream startAt option, but this requires duplicating the option definition, and screams bad practice to me.

This appears to be the road most often taken in nixpkgs modules. See for example nix.gc.dates.

It also demonstrates exactly why I think this is bad practice - nix.gc.dates is str, while systemd.services..startAt is either str (listOf str), so the garbage collection module loses the flexibility of defining multiple timers. This would not be the case if it inherited the option definition somehow.

Currently, I’d like to do something similar with home-manager’s xdg.desktopEntries , which are a submodule to boot. Ideally I’d like to grab a subset of the submodule settings, and import them at the top level of my module, while maybe changing a few defaults (essentially looking for a .override on mkOption).

Is the NixOS module system just not flexible enough for this, or is there actually a good way of achieving this I’ve not run into before?

2

We should add a new type for systemd timers

3

I take it that means there’s no generic way of reusing options without a full type definition? :slight_smile:

4

You could import it from another module but thats ugly and services shouldn’t rely onto each other for type definitions that are totally unrelated.

5

Regardless of this particular use case, this can be achieved with something like:

options = {
    option = (import ./another-module.nix { inherit pkgs config lib; }).another-module.options.option;
};