NixOS Module System | 148 Members | |
| 30 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Dec 2025 | ||
| i have not yet setup/learned how sopsnix works, so I am unsure tbh | 02:59:31 | |
| agenix/sopsnix encrypt and pass files | 02:59:42 | |
| i see, okay thanks | 02:59:57 | |
| then ill re-evaluate how i go about this. but thanks for the advice regardless! | 03:00:17 | |
| 08:08:40 | ||
| 08:25:17 | ||
okay, i've been working on the PR for the nixos/bore module, but I'm at a bit of a roadblock when it comes to nixos tests. Since bore local requires a connection to a remote proxy server (i.e. "bore.pub"), should the nixos tests really be connecting to it to verify functionality? Rather, how does networking work with the test suite? Or should I only run tests for the server variant, which simply needs to check if it can listen on 0.0.0.0:<specified port>? | 20:59:24 | |
| actually i think i might be able to set up a server and a local proxy on the same machine that just interact with each other | 21:14:52 | |
| 20 Dec 2025 | ||
| if anyone has free time, could you skim over this PR and see if things look fine? https://github.com/NixOS/nixpkgs/pull/472353 I'm hoping to ask some non-reviewers before I post in the Nixpkgs Review Requests, just so I can minimize the number of cycles I approach reviewers, who might be busy. Thanks in advance! | 02:39:01 | |
| * if anyone has free time, could you skim over this PR and see if things look fine? https://github.com/NixOS/nixpkgs/pull/472353 I'm hoping to ask some non-reviewers before I post in the Nixpkgs Review Requests channel, just so I can minimize the number of cycles I approach reviewers, who might be busy. Thanks in advance! | 02:39:10 | |
| 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 | |