| 31 Mar 2026 |
|  Kwinsi Thakkar joined the room. | 16:34:17 |
 Yyovil | ADHD people? Anyone? | 19:06:50 |
 Jacobus Burger | huh? | 23:51:57 |
| 2 Apr 2026 |
|  Sanskar set a profile picture. | 08:03:07 |
| Sanskar | Hey @roberth (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? | 10:20:41 |
| Sanskar | * 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? | 10:21:35 |
| Sanskar | * Hey @roberthensing (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? | 10:22:03 |
|  @clay53:claytonhickey.me left the room. | 15:22:55 |
| Sanskar | * 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? | 15:45:50 |
 Robert Hensing (roberth) | manual wiring at first to minimize impact on users as modular services gains traction | 18:27:52 |
| 5 Apr 2026 |
|  ritiek changed their profile picture. | 01:18:08 |
| 8 Apr 2026 |
|  Skoh left the room. | 12:17:26 |
|  @marvesms:matrix.org joined the room. | 21:31:58 |
|  NixOS Moderation Bot banned @marvesms:matrix.org (spam). | 22:01:00 |
| 9 Apr 2026 |
|  Lisanna changed their profile picture. | 21:59:40 |
| Lisanna changed their profile picture. | 22:00:58 |
| Lisanna changed their profile picture. | 22:02:08 |
| Lisanna changed their profile picture. | 22:12:31 |
| Lisanna changed their profile picture. | 23:14:54 |
| 11 Apr 2026 |
|  gaurav_aditya 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 left the room. | 10:42:34 |
