NixOS Module System | 148 Members | |
| 30 Servers |
| Sender | Message | Time |
|---|---|---|
| 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 | |
| 25 Feb 2024 | ||
| 22:43:41 | ||
| 1 Mar 2024 | ||
| 04:27:37 | ||
| 7 Mar 2024 | ||
| How does the module system handle definitions with no priority? I've got two modules
If I evaluate them together, I get I imagine the answer is somewhere in this function but I am having trouble working through the logic. On a side note, this appears to be the place where option declarations with a | 04:41:32 | |
After digging some more it seems like it actually might happen in mergeDefinitions which calls filterOverrides'. My reading of it leads me to believe that definitions with no priority get set a priority of defaultOverridePriority which is fairly low (100). | 05:15:44 | |
| 9 Mar 2024 | ||
| 00:39:08 | ||
| 14 Mar 2024 | ||
| 18:44:27 | ||
| 15 Mar 2024 | ||
| 04:06:23 | ||
| 16 Mar 2024 | ||
| 02:12:10 | ||
| 14:00:14 | ||
| 17 Mar 2024 | ||
| 20:43:44 | ||