Modular Services meeting #9 2026-10-02

Development
1

Modular Services meeting #9 2026-10-02

Attendees: @eveeifyeve @lassulus @roberth @tomberek @kiara

  • @eveeifyeve: what is package modules and what are the main benefits it brings?

  • @lassulus: a way to write wrappers for packages

    myNginx = pkgs.nginx.module.configure {
  virtualHosts.test.locations."/" = {
    proxyPass = "http://localhost:1234";
  };
};
systemd.services.myNginx = myNginx.systemdService;

    dependant services

    peertubeModule = { config, ... }: {
  settings = ...
  nginx.options = pkgs.nginx.module.options;
  nginx.config.virtualHosts.${config.settings.name}... 
};

    generating just a config file

    mpvModule = { config, ... }: {
  settings = lib.mkOption { ... };
  mpvConf = lib.mkOption {
    default = settingsToCfg config.settings;
  };
};

mpv_cfg = mpvModule.configure {
  ...
}.config.mpvConf

  • @lassulus: could be used in many ways: wrapper script, systemd service, or whatever else

  • @eveeifyeve: so great for generalization. Does it have other benefits?

  • @lassulus: yes, that is the main benefit. Maybe performance, as it also allows a smaller NixOS module list

  • @eveeifyeve: been looking into performance with @tomberek. Did some testing with a minimal module list.

  • @tomberek: we tried to measure how much the superfluous imports cost. Removing half gives a 13% improvement. Couldn’t remove the “nastiest” big ones.

  • @tomberek: unknowns: types.record, whether this would be made worse with package modules. Self-containedness seems promising

  • @lassulus: dependencies between services are unsolved in package modules

  • @roberth: [chat] some years ago I tried a minimal postgresql NixOS host, got eval down by 3×

  • @kiara: a “mistake” perhaps we made with NixOS is we’ve made it easy to get things up and running on a single host, but multi-host wiring is an open problem. Spending some effort there with @ibizaman

  • @eveeifyeve: I plan to work on building a modular service implementation on nixops4.

  • @kiara: how would that fit into nixops4?

  • @eveeifyeve: nixops4 is for push based deployments. Unlike deploy-rs, colmena, reduces the need for plugins - providers instead.

  • @roberth: nixops4 is mostly just an outer layer. You could build all the modular services stuff without it. For instance deploying a mutable set of services onto NixOS

  • @kiara: what do you want out of it?

  • @eveeifyeve: deploy infra fully with Nix. IaC. Unlike colmena, nixops4 has a nesting structure for resources. I’d like to build something based on the nixops4-nixos architecture.

  • @kiara: so you see an analogy between subservice structure and nixops4 nesting?

  • @eveeifyeve: yes

  • @kiara: modules already allow this nesting. It doesn’t seem like terraform-like per-resource updates are the shape we’re really looking for.

  • @eveeifyeve: some of my services are very stateful. E.g. matrix

  • @kiara: did you see Alexander Foremny’s NixCon talk? Taking terraform providers to target specific services and exposing those as NixOS modules, so that they can manage the stateful part of the configuration. (applicative-systems/declarative-runtime)

  • @kiara: since last time if played around to see if config file generation could be factored out from NixOS, postgresql: add modular service and integrations by KiaraGrouwstra · Pull Request #25 · KiaraGrouwstra/modular-services · GitHub

  • @roberth: [chat] in the sense of [RFC 0078] System-agnostic configuration file generators by 7c6f434c · Pull Request #78 · NixOS/rfcs · GitHub?

  • @kiara: looking at the package modules / wrappers examples, did you consider exposing that as a module instead of a call that returns one?

  • @lassulus: I’m not attached to the details, but this is how I would generally expect it to look. This is like a demo.

  • @kiara: The examples look like modular services. I get the impression that this functions as those would.

  • @lassulus: the examples were a bit rushed. Happy to change things, which is possible.

  • @eveeifyeve: I’d like the modules to reside in packages, including system-wide ones

  • @roberth: we should probably be careful about scoping to make sure we can still actually get things done.

  • @roberth: so for package modules the main goal is to align the options

  • @roberth: homework: look at the code on the other side of the fence and compare

  • @roberth: I wasn’t clear on who was taking up the modular services users support. I won’t have time in the coming two weeks. @eveeifyeve, feel free to pick that up. Resources:

    • the issue
    • validate it with use cases:
      • simple, no users
      • services with same-user constraints but no names or ids. Names can be derived from the service attribute path. Ids use existing solutions like NixOS id-less users (mutable-users or otherwise).
      • services with user names
      • services with all information pinned down
      • services with ids pinned down but not using default names

Action Items:
- @eveeifyeve: rebase nixos/phpfpm: set systemd Type to notify-reload when possible by aanderse · Pull Request #434262 · NixOS/nixpkgs · GitHub and make use of reloadCommand and reloadSignal.
- @eveeifyeve: User Creation/Spec
- everyone: look into package modules options and compare

5 Likes