Sender | Message | Time |
---|---|---|
27 May 2024 | ||
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 |
nbp |
| 12:50:38 |
Sam Lehman | If I collected all nixosModules from my inputs and set a key=<inputName>-<moduleName> attr, would this allow multiple imports of the same nixosModule ? | 12:51:11 |
Sam Lehman | Is key an attr of modules that gets handled by lib.evalModules ? Like I could specify a key attr inside a module definition, then import the same module in two places without error? | 12:52:12 |
nbp | I would say that an upstream issue, others would have the same problem as you, so you might as well fix it upstream. | 12:52:21 |
Sam Lehman | Is there any documentation on this behavior? | 12:52:23 |
nbp | key has been there since the beginning of the module system. | 12:53:21 |