NixOS Module System | 142 Members | |
| 29 Servers |
| Sender | Message | Time |
|---|---|---|
| 21 Oct 2025 | ||
| 20:56:17 | ||
| 23 Oct 2025 | ||
| 21:02:11 | ||
| 24 Oct 2025 | ||
| 04:41:41 | ||
| 20:35:16 | ||
| 1 Nov 2025 | ||
| 22:53:22 | ||
| 22:54:19 | ||
| 4 Nov 2025 | ||
| 08:23:11 | ||
| 08:34:45 | ||
| 7 Nov 2025 | ||
| 22:42:52 | ||
| 9 Nov 2025 | ||
| 15:24:51 | ||
| 8 Feb 2024 | ||
| 10:38:02 | ||
| 15 Feb 2024 | ||
| 19:15:14 | ||
| 16 Feb 2024 | ||
| 14:56:15 | ||
| 14:59:24 | ||
| I recently stumbled upon similar issue when working on home-manager. https://discourse.nixos.org/t/is-it-possible-to-define-systemd-services-in-a-submodule/39538/5 The idea is that enabling https://nix-community.github.io/home-manager/options.xhtml#opt-programs.bash.enableCompletion should set I think that module system is missing an option to pass config options recursively up to all ancestors. | 15:06:01 | |
My idea is that nixos config could have a property extraNixosChildConfig and in home-manager bash module I could set _recurseAncestors = { extraNixosChildConfig = { environment.pathsToLink = [ ... ]; }; }. | 15:07:22 | |
| wdyt? | 15:07:26 | |
* My idea is that nixos config could have a property extraNixosChildConfig that gets merged with the rest of the config and in home-manager bash module I could set _recurseAncestors = { extraNixosChildConfig = { environment.pathsToLink = [ ... ]; }; }. | 15:07:44 | |
* My idea is that nixos config could pick up extraNixosChildConfig from childs and merge it with the rest of the config and in home-manager bash module I could set _recurseAncestors = { extraNixosChildConfig = { environment.pathsToLink = [ ... ]; }; }. | 15:08:21 | |
| Not sure about that recursive thing, that doesn't seem necessary, but yeah if there's something missing in the NixOS module for home-manager, that could be added | 15:34:09 | |
| Sounds like an issue for the home-manager repo | 15:34:16 | |
| Yeah, we could add it just for home-manager. But is seems like the issue is quite generic. See also https://github.com/NixOS/nixpkgs/pull/152785. | 15:51:50 | |
| Hmm yeah fair. I don't have the capacity to think a lot about this right now, it's a very intricate topic to wrap ones head around | 15:56:55 | |
| Yeah, I just wanted to bring the topic, maybe someone has some interesting thoughts. | 16:05:23 | |
| 17:49:31 | ||
| 20 Feb 2024 | ||
| I'm reading through the module system deep dive on nix.dev and am wondering if there is a behavioral difference between setting an options default behavior in the this
vs this
| 21:39:27 | |
djacu: Setting a default with options.foo = lib.mkOption { default = <value>; ... } is equivalent to config.foo = lib.mkOptionDefault <value>; | 23:23:21 | |
Furthermore, default = <value> (and there's defaultText too) can get rendered in the manual, config.foo = ... can't | 23:24:14 | |
| Right right I forgot about the docs side. I was more focused on merge behavior. So either way they get default priority. Thanks for the explanation! | 23:48:23 | |
| 21 Feb 2024 | ||
| djacu (Well you need mkOptionDefault to get the same priority for config, which is generally not done) | 11:25:22 | |