Modular services meeting #6 2026-08-07
Attendees: @aanderse @kiara @eveeifyeve @roberth + 3 guests
-
@eveeifyeve: apologies for my PR. What is the status of CI?
- @kiara: downstream consumers make it harder still, e.g. the problem with home manager using our Nixpkgs stuff in an unanticipated way
- @eveeifyeve: could we have more eval tests in lib?
- @kiara: that only gives limited coverage. Couldn’t we test it more in a Nixpkgs context?
- @roberth: I think we need to figure out with CI how to trigger the right reverse dependencies
- @lassulus: We don’t have any capability to run NixOS VM tests in GHA or nixpkgs-review
- @roberth: We could at least test a different service manager that doesn’t require virtualization. That would give us coverage of the portable stuff and a large part of the compliance suite
-
@eveeifyeve: contracts, could we make a portable api to it that’s not NixOS-specific
- @kiara: it wasn’t NixOS-specific
- @eveeifyeve: I was wondering about ibizaman’s PR
- @kiara: his initial work was NixOS-specific, but I’ve made it portable
- @eveeifyeve: would be good for e.g. secrets
- @kiara: this would need some code duplication because NixOS and modular services have different option spaces
- @eveeifyeve: defining secrets across multiple hosts is challenging
- @kiara: duplication is probably solvable but we needed to start out simple
- @kiara: for fediversity I use openbao and a vars-like mechanism with contracts
- @lassulus: vars is in good state for NixOS, could be made portable in followup
- @kiara: utils: init genSecretsReplacement by ibizaman · Pull Request #503858 · NixOS/nixpkgs · GitHub
- @kiara: not even NixOS has solution, so not sure this is in scope for modular services?
- @eveeifyeve: it is a blocker for databases
-
@roberth: package modules, status update?
- @lassulus: side tracked past month
- @kiara: I used the term in the docs PR as well
- @eveeifyeve: what changes?
- @kiara: just the name, and more widely usable
- @eveeifyeve: would appreciate more reviews on lib/services/service: add flags and flagFormat options by KiaraGrouwstra · Pull Request #546008 · NixOS/nixpkgs · GitHub
-
@eveeifyeve: relevant for nix on windows too
- @kiara: what is the status of that?
- @eveeifyeve: me and @tomberek have been working on a prototype for incremental builds
- @eveeifyeve: I’d like to work on a stdenv for mingw
-
@eveeifyeve: how’s progress on user creation
-
@eveeifyeve: how can we increase adoption
- @roberth: we could iterate faster out-of-tree
- @kiara: out-of-tree we could also observe what boilerplate we need to clean up
- @eveeifyeve: it’s important
- @kiara: not having to worry about breakage would be very helpful
- @kiara: do we really want more modules
- @aanderse: I agree with Kiara that we don’t want to push for more modules and users because the interface is still almost entirely useless, except for rare use cases. The problem is that the hurdles haven’t been addressed yet, and when that’s done the floodgates can open
- @aanderse: If we push before e.g. users is implemented, that would not fly with many NixOS folks
- @eveeifyeve: what is the consensus about hardening
- @roberth: great question! this is something we need to figure out
- @roberth: both the escape hatch and generalization into portable options have a place
- @aanderse: how do we make security mechanisms work, with something like a decorator pattern? for apparmor, bubblewrap, etc
-
@kiara: do we move forward with the new repo?
- @kiara: do we pin NixOS?
- @eveeifyeve: we should fork Nixpkgs, worked for cygwin
- @roberth: if we also fork we can’t use our fork with cygwin
- @kiara: I don’t think forking is helpful; can we use nixpkgs as an input
- @roberth: disabledModules
- @aanderse: you’re taking yourself out of the privileged position of being in the monorepo
- @roberth: probably ok for now
-
PR Reviews…