Sender | Message | Time |
---|---|---|
9 May 2024 | ||
SomeoneSerge (utc+3) changed their display name from SomeoneSerge (Way down Hadestown) to SomeoneSerge (UTC+3). | 17:11:29 | |
14 May 2024 | ||
chrillefkrr joined the room. | 15:44:45 | |
infinisil changed their profile picture. | 17:44:47 | |
f44 joined the room. | 17:53:10 | |
16 May 2024 | ||
@nuko:shimeji.cafe left the room. | 06:19:54 | |
20 May 2024 | ||
mei 🌒& changed their display name from ckie (they/them) to mei 🌒&. | 00:05:44 | |
21 May 2024 | ||
pxc | if I want to pass a whole NixOS configuration (a nixosConfigurations.<whatever> flake output) to a module, what type should I say it is? does a top-level configuration have a type represented in Nixpkgs lib.types ? | 02:27:09 |
pxc | can I do better than types.attrs ? | 02:27:58 |
nbp | the output of a NixOS configuration depends on what is being configured, so the "type" is dependent on what is being configured. This is what submodules are | 09:17:09 |
nbp | submodules are a non-evaluated set of modules which would be evaluated to compute the result. | 09:17:39 |
nbp | If you look at the various virtualisation options, you will find some which are re-importing NixOS modules, or suggesting to make mutation to the system configuration IIRC | 09:18:41 |
22 May 2024 | ||
NixOS Moderation Botchanged room power levels. | 15:25:50 | |
NixOS Moderation Botchanged room power levels. | 15:28:05 | |
@infinidoge:matrix.org changed their display name from Infinidoge to Migrated to @infinidoge:inx.moe. | 21:36:24 | |
Infinidoge 🏳️⚧️ joined the room. | 22:19:53 | |
@infinidoge:matrix.org left the room. | 22:21:14 | |
Infinidoge 🏳️⚧️ changed their display name from Infinidoge 🏳️⚧️ to Migrated to @infinidoge:inx.moe. | 22:35:31 | |
Infinidoge 🏳️⚧️ changed their display name from Migrated to @infinidoge:inx.moe to Infinidoge. | 22:37:11 | |
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 |