Sender | Message | Time |
---|---|---|
27 May 2024 | ||
nbp | * Sam Lehman: Yes, evalModules should capture the whole tree of imports and deduplicated moduled key property.However, if you are using flakes, and define a nixosModules within the flake.nix file, then the key attribute is not initialized to any value which can safely be deduplicated. | 09:43:28 |
nbp | infinisil: I just watch your stream from a month ago. _options used to be the default, except that it got removed in favor of toJSON / toTOML functions 🤦 | 17:07:25 |
nbp | * infinisil: I just watch your stream from a month ago. _options used to be the default in submodules, except that it got removed in favor of toJSON / toTOML functions 🤦 | 17:07:36 |
infinisil | @nbp:mozilla.org Aren't you thinking of _module? | 17:09:00 |
infinisil | I'm the one who removed that in submodules ;) | 17:10:35 |
nbp | Yes _module was one way to expose the internal details. | 17:12:15 |
nbp | There are multiple problems to finding the declarations of a submodule option. | 17:12:47 |
nbp | One of them is the apply function, which implies that the content would be post-processed. | 17:13:32 |
nbp | Another one, which I bet nobody noticed, is that you can add submodules at the definition site:
| 17:19:11 |
nbp | Adding color is point-less, but for example, one could import a home-manager configuration this way. | 17:19:35 |
nbp | * Another one, which I bet nobody noticed, is that you can add submodules at the definition site:
| 17:21:05 |
nbp |
| 17:22:12 |
nbp | I will note that the former is better than
as the later will lose the file attribute associated with | 17:31:59 |
28 May 2024 | ||
Sam Lehman | This is a pretty basic example of what I'd like to be able to do, where the import could also be another profile instead of a
| 12:11:12 |
Sam Lehman | In reply to @infinidoge:inx.moe This is similar to something else I was considering separately, but I was also trying to make each profile fully standalone, so I could safely import and enable them without conflicts. Can a I want to do something like this programmatically, where all my profiles get collected and wrapped inside a | 12:25:21 |
nbp |
| 12:30:20 |
nbp | *
No, because | 12:30:28 |
nbp | You can create an option, which value is used as part of:
| 12:32:21 |
Sam Lehman | In reply to @nbp:mozilla.org Not sure I follow. Is I'm also using https://github.com/divnix/std and I'd like to reference other profiles using | 12:34:18 |
Sam Lehman | In reply to @nbp:mozilla.orgThat's what I thought | 12:34:43 |
Sam Lehman | In reply to @nbp:mozilla.org I don't think this structure will work for how I'm trying to set my profiles up. I might be able to create | 12:38:48 |
nbp | If you can just import them all, and use mkIf as described above. | 12:40:43 |
nbp | I doubt the above would not work, unless you have circular dependencies, as the code above is how NixOS is written, and it work, AFAIK. | 12:41:31 |
nbp | * I doubt the above would not work, unless you have circular dependencies, as the code above is how NixOS is written, and it works, AFAIK. | 12:41:37 |
Sam Lehman | My config eval errors for me if I enable two profiles that both import the same nixosModule , and if imports can't be gated by mkIf , I think I'm stuck with that problem. | 12:45:32 |
nbp | If they error while importing the same nixosModule , this is because the module system is unable to find a unique identifier to use as a key to deduplicate the 2 imports. | 12:48:27 |
nbp | This happens with flakes which are just providing unnamed modules. | 12:48:50 |
nbp | Using the key attribute next to config would help resolve that, or by moving the module to a file, and not importing it in the flake. | 12:49:37 |
Sam Lehman | hmmm, is there a way to manually give it a key? I have no idea how this part works? | 12:49:43 |
Sam Lehman | * hmmm, is there a way to manually give it a key? I have no idea how this part works | 12:49:50 |