NixOS GSoC | 247 Members | |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 12 Apr 2026 | ||
| * 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 | |
| * 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 | |
| * 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 | |
| 10:42:34 | ||
| 18:43:59 | ||
| 13 Apr 2026 | ||
| 05:16:49 | ||
| 18 Apr 2026 | ||
| 18:39:10 | ||
| 20:32:23 | ||
| 19 Apr 2026 | ||
| 09:23:26 | ||
| 20 Apr 2026 | ||
| 22:05:26 | ||
| 23 Apr 2026 | ||
| 07:41:40 | ||
| 12:27:31 | ||
| 24 Apr 2026 | ||
| 05:42:01 | ||
| 05:49:59 | ||
| 25 Apr 2026 | ||
| 23:12:39 | ||
| 27 Apr 2026 | ||
| 14:57:14 | ||
| 29 Apr 2026 | ||
| 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 | |
In reply to @sanskar-0day:matrix.orgone 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 | |
| 14:47:53 | ||
| 17:28:41 | ||
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 | |
| 30 Apr 2026 | ||
| That's interesting, if the identity contract ends up being roughly equivalent to just writing a custom snid contract, it kind of suggests the inference step doesn't actually save much. Maybe the real value of automation isn't generating the contract itself, but just helping figure out which boundaries actually need one? | 05:58:21 | |
In reply to @sanskar-0day:matrix.orgif we're talking inter-service boundaries, I think grepping service modules for `services\.\w+.* =` should go a long way in finding what else they set | 07:57:54 | |
| Agreed. Grepping gets us the obvious write boundaries for cheap, leaving a much smaller surface area to manually audit. Certainly better than overengineering it. | 09:18:58 | |
| Thanks Tristan Ross and Robert Hensing (roberth). Forever grateful to yall for this opportunity. | 18:15:23 | |
| Just posted the announcement on community Discourse | 19:55:50 | |
| 1 May 2026 | ||
| 12:59:49 | ||
| 4 May 2026 | ||
| 02:36:05 | ||
| 3 May 2026 | ||
| 13:02:40 | ||
| 20:17:42 | ||