| 9 Apr 2026 |
|  Lisanna changed their profile picture. | 22:12:31 |
| Lisanna changed their profile picture. | 23:14:54 |
| 11 Apr 2026 |
|  @gaurav_aditya:matrix.org changed their display name from gaurav_aditya to Aditya Gaurav. | 01:38:10 |
|  Robert Hensing (roberth) invited  @cinerealkiara:matrix.org. | 09:43:17 |
| @cinerealkiara:matrix.org joined the room. | 12:14:51 |
| 12 Apr 2026 |
 Jacobus Burger | How is everyone doing today? | 01:20:16 |
 Allan Dinakaran | Good how about you? | 02:24:52 |
| @cinerealkiara:matrix.org | In reply to @sanskar-0day:matrix.org
Hey @roberthensing:matrix.org (and anyone else around), I'm looking into the Modular Services GSoC project and had a quick architecture question.
Since the project description explicitly requires keeping the user-facing options of the NixOS module the same, I’m curious about the intended migration strategy. Is the plan to manually wire up the legacy global options to the new modular backend for each service one-by-one? Or is the goal to build a standardized abstraction (like a mkModularService wrapper) that automatically bridges the legacy options to the new modular instances? this seems hard to automate since a nixos service module doesn't in a straight-forward manner map to a (systemd) service - they can span heterogeneous services (e.g. need a db) or spin up a set of similar services | 07:55:28 |
| @cinerealkiara:matrix.org | Redacted or Malformed Event | 07:56:29 |
| @cinerealkiara:matrix.org | * this seems hard to automate since a nixos service module doesn't in a straight-forward manner map to a (systemd) service - they can span heterogeneous services (e.g. need a db) or spin up [a set of similar services](https://github.com/NixOS/nixpkgs/pull/506645) | 08:21:36 |
| @cinerealkiara:matrix.org | * this seems hard to automate since a nixos service module doesn't in a straight-forward manner map to a (systemd) service - they can span heterogeneous services (e.g. need a db, example test at [contracts PR] (https://github.com/NixOS/nixpkgs/pull/506343)) or spin up [a set of similar services](https://github.com/NixOS/nixpkgs/pull/506645) | 08:24:14 |
| @cinerealkiara:matrix.org | * this seems hard to automate since a nixos service module doesn't in a straight-forward manner map to a (systemd) service - they can span heterogeneous services (e.g. need a db, example test at [contracts PR](https://github.com/NixOS/nixpkgs/pull/506343)) or spin up [a set of similar services](https://github.com/NixOS/nixpkgs/pull/506645) | 08:24:38 |
| @gaurav_aditya:matrix.org left the room. | 10:42:34 |
|  @scrumplex:duckhub.io joined the room. | 18:43:59 |
| 13 Apr 2026 |
|  @othiagomm:matrix.org left the room. | 05:16:49 |
| 18 Apr 2026 |
|  @sboukiou:matrix.org left the room. | 18:39:10 |
| @scrumplex:duckhub.io left the room. | 20:32:23 |
| 19 Apr 2026 |
|  comonad joined the room. | 09:23:26 |
| 20 Apr 2026 |
|  @ninio_artillero:kde.org left the room. | 22:05:26 |
| 23 Apr 2026 |
|  天川理音 joined the room. | 07:41:40 |
|  @not-jack:matrix.org left the room. | 12:27:31 |
| 24 Apr 2026 |
|  @hytero:r4.fo joined the room. | 05:42:01 |
| @hytero:r4.fo left the room. | 05:49:59 |
| 25 Apr 2026 |
|  kekser joined the room. | 23:12:39 |
| 27 Apr 2026 |
|  Ninja joined the room. | 14:57:14 |
| 29 Apr 2026 |
 Sanskar | kiara: Reading through the easyturn (#506645) and contracts (#506343) PRs more carefully, I think I get now why a generic wrapper doesn't work.
They're actually two different failure modes: easyturn breaks because a flat legacy option space can't map to named instances without knowing the cardinality upfront, while contracts breaks because the module spans a runtime dependency graph that has no single modular equivalent.
One thing I'm still not clear on: if the contracts PR lands, does migration for a dependent service become two separate steps? First map it to its modular shape, then manually audit and add the contract declarations? Or is there a way the contract requirements get derived from the existing config references?
| 11:01:22 |
| @cinerealkiara:matrix.org | In reply to @sanskar-0day:matrix.org
kiara: Reading through the easyturn (#506645) and contracts (#506343) PRs more carefully, I think I get now why a generic wrapper doesn't work.
They're actually two different failure modes: easyturn breaks because a flat legacy option space can't map to named instances without knowing the cardinality upfront, while contracts breaks because the module spans a runtime dependency graph that has no single modular equivalent.
One thing I'm still not clear on: if the contracts PR lands, does migration for a dependent service become two separate steps? First map it to its modular shape, then manually audit and add the contract declarations? Or is there a way the contract requirements get derived from the existing config references?
one could imagine taking an submodule option shape as a request shape, tho the question might be what to take as the result if we wanna infer things: none? same submodule tree?
like the honest answer here is i haven't actually tried to do this yet. | 11:13:04 |
|  Swaraj set a profile picture. | 14:47:53 |
|  KangYu Peng joined the room. | 17:28:41 |
| @cinerealkiara:matrix.org | i tried to further explore the idea of identity contracts generated from a modular service's submodule option shape for the case of our existing modular service snid, but didn't so much get to something particularly more useful than just a custom snid contract aimed at this boundary (in which case... maybe a more generic contract for such a use-case might do as well) | 18:51:38 |
