Sender | Message | Time |
---|---|---|
23 May 2024 | ||
Infinidoge 🏳️⚧️ changed their display name from Infinidoge to Infinidoge🏳️⚧️. | 01:31:17 | |
Infinidoge 🏳️⚧️ changed their display name from Infinidoge🏳️⚧️ to Infinidoge 🏳️⚧️. | 01:31:27 | |
26 May 2024 | ||
Sam Lehman | I want to have several profile configs that all import the same base profile config or nixosModules, but I'd like to be able to import multiple of them simultaneously, which results in an error. My goal is to have each profile work as a fully standalone unit, but also be granularly composable into more featured profiles. Is there some pattern that would allow this organization scheme? | 10:34:14 |
Sam Lehman | If Is there some behavior of the module system that depends on being able to apply the same import multiple times while building the options attrset? | 10:37:03 |
@djacu:matrix.org | Sam Lehman: do you have some example code you could link to? | 14:31:39 |
27 May 2024 | ||
Infinidoge 🏳️⚧️ | In reply to@lehmanator:tchncs.deProbably the easiest way to accomplish something like this would be to have all of the profiles imported, but control what gets applied with options Something like: common :` nixoptions = { profile1 = lib.mkOption { type = lib.types.bool; default = false; }; profile2 = lib.mkOption { type = lib.types.bool; default = false; }; profile3 = lib.mkOption { type = lib.types.bool; default = false; }; }; config = { # Common config here };
And so on | 01:33:16 |
Infinidoge 🏳️⚧️ | Probably the easiest way to accomplish something like this would be to have all of the profiles imported, but control what gets applied with options Something like: common :` nixoptions = { profile1 = lib.mkOption { type = lib.types.bool; default = false; }; profile2 = lib.mkOption { type = lib.types.bool; default = false; }; profile3 = lib.mkOption { type = lib.types.bool; default = false; }; }; config = { # Common config here }; ` profile1 :
| 01:33:16 |
Infinidoge 🏳️⚧️ | Matrix, why must you pain me | 01:33:24 |
Infinidoge 🏳️⚧️ | Probably the easiest way to accomplish something like this would be to have all of the profiles imported, but control what gets applied with options Something like: common :` options = { profile1 = lib.mkOption { type = lib.types.bool; default = false; }; profile2 = lib.mkOption { type = lib.types.bool; default = false; }; profile3 = lib.mkOption { type = lib.types.bool; default = false; }; }; config = { # Common config here }; ` profile1 :
| 01:33:40 |
Infinidoge 🏳️⚧️ | Probably the easiest way to accomplish something like this would be to have all of the profiles imported, but control what gets applied with options Something like: common: ` options = { profile1 = lib.mkOption { type = lib.types.bool; default = false; }; profile2 = lib.mkOption { type = lib.types.bool; default = false; }; profile3 = lib.mkOption { type = lib.types.bool; default = false; }; }; config = { # Common config here }; ` profile1:
| 01:34:20 |
Infinidoge 🏳️⚧️ | Probably the easiest way to accomplish something like this would be to have all of the profiles imported, but control what gets applied with options Something like: common:
| 01:34:41 |
nbp | Sam Lehman: Yes, evalModules should capture the whole tree of imports and deduplicated moduled key property.However, if you are using flakes, the key attribute is not initialized if the module is not listed as a path, to be imported by the module system. | 09:42:10 |
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 |