Modular services meeting #5 2026-07-24

Development
1

modular services meeting 2026-07-24

Attendees: @aanderse @KiaraGrouwstra @Eveeifyeve @roberth

  • @KiaraGrouwstra: should we be using upstream files?

    • @aanderse: NixOS should do this, it does, which is good, but generally we ship a lot of opinion on top of those
    • @Kiara: emilazy was interested in this argument for nix-darwin
    • @roberth: this approach wouldn’t support multi-instance modularity

  • @Eveeifyeve: tmpfiles. Multiple implementations exist. I’d like to make that portable. Not sure about implementation detail

    • @roberth (prior on matrix): not a fan of the syntax
    • @aanderse: it seems that the open source world has agreed that doing this through some files is more robust than shell scripts. Worth discussion. Alternatives exist
    • @roberth: very helpful if we could pass a file name to the tool, because a system-wide tmpfiles doesn’t run right before switch, when it needs to
    • @aanderse: RuntimeDir is obviously tied to lifecycle, but state directories traditionally not necessarily, but I think there’s value in it
    • @aanderse: To a critic who doesn’t want tmpfiles, what do we tell them?
    • @Eveeifyeve: They don’t have to use it, like you wouldn’t use a non-portable C function
    • @aanderse: Then perhaps we don’t need to cover it in the modular service interface, and an implementation can choose to provide/use tmpfiles or not
    • @evee: What should the interaction with user permissions look like?
    • @aanderse: I wouldn’t mind systemd’s API
    • @roberth: User management is somewhat of a prerequisite for file system stuff

  • @KiaraGrouwstra: what do we think of the approach of platform-specific modules?

    • @roberth: makes composition harder
    • @KiaraGrouwstra: new modularServices option can solve that
    • @roberth: agreed, reminds of overlays
    • @KiaraGrouwstra: how do we build this out
    • @roberth: maybe call it registry? Kind of like a package set, but of modules.
    • @roberth: could reuse the by-name infrastructure?
    • @KiaraGrouwstra: no strong opinion on file location, pkgs/by-name would be a layer violation
    • @roberth: claim a top-level dir? The portable parts are between the packages layer and NixOS layer
    • @roberth: so portable parts go into pkgs, possibly by-name, NixOS parts go into nixos/
    • @Eveeifyeve: I think we should still focus on building out the portability through options
    • @roberth: agree, but the registry is simple and has value of its own

  • @KiaraGrouwstra: on sub-services, I’d like to have something like contracts

    • @roberth: absolutely, can do both, and multi-service package should be a two-layer activity: contract-based first, modules that compose those on top. Users can choose.

  • @KiaraGrouwstra: what do we prioritize. E.g. people are creating services. Maybe we need to focus on our capabilities first. Some PRs have been open for a while. How do we prioritize? What are values based on which to review and decide?

  • Pr Reviews

  • @KiaraGrouwstra: what are our priorities and shape of roadmap

  • @KiaraGrouwstra: maybe one for me would be outstanding question marks

  • @aanderse: i’m just here to advise from the perspective of an external existing system

    • few services, i doubt anyone is depending on this already

  • @roberth:

    • Need to solve a number of pain points before significantly expanding set of services, let alone allowing NixOS to depend on them
      Perhaps:
      • Stage 1:
        • do not merge more than 20 modular services, require maintainer buy-in, no usage in NixOS modules (ie need duplication)
        • add more portable options
        • make it reasonably secure on NixOS: user support
        • add the registry
      • Stage 2:
        • allow more services, allow different person than package/NixOS maintainer to maintain modular service
        • keep building out portable options
        • solve other pain points
        • contracts
      • Stage 3:
        • allow use by NixOS modules
        • experimental → stabilizing
      • Stage 4: profit

  • @Eveeifyeve: put growing NixOS services on hold until this gets more mature (in terms of portability APIs), now trying to make a modular service for a database

  • @KiaraGrouwstra: if we got ideas on TODOs let’s file them in the issue tracker for the kanban

    • @roberth: ok i’ll file one on service users

  • @roberth: opened [modular services] User creation/specification · Issue #545287 · NixOS/nixpkgs · GitHub

We did a bit of work session after the meeting.
We have a label and a board now :tada:

5 Likes