| 4 May 2024 |
|  ShalokShalom removed their profile picture. | 11:27:03 |
| ShalokShalom set a profile picture. | 11:27:13 |
|  SomeoneSerge (migrating synapse) changed their display name from SomeoneSerge (is taking time off and doesn't want to hear about it) to SomeoneSerge (Way down Hadestown). | 21:03:46 |
| 8 May 2024 |
|  checooh joined the room. | 11:57:41 |
| 9 May 2024 |
| SomeoneSerge (migrating synapse) 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 |
|  fsnkty 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 changed their display name from Infinidoge to Migrated to @infinidoge:inx.moe. | 21:36:24 |
| Infinidoge 🏳️⚧️ joined the room. | 22:19:53 |
| Infinidoge 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 lib.evalModules recursively enumerates the entire tree of imports prior to config eval, and each path in imports is uniquely identifable, why does it opt to throw an error instead of filtering the paths of the merged imports list with something like lib.unique?
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 | Sam Lehman: do you have some example code you could link to? | 14:31:39 |
| 27 May 2024 |
| Infinidoge 🏳️⚧️ | In reply to@lehmanator:tchncs.de
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? 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:
`nix
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`:
```nix
config = lib.mkIf config.profile1 {
# Profile 1 config here
};
```
`profile2`:
```nix
config = lib.mkIf config.profile2 {
# Profile 2 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:
`nix
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:
config = lib.mkIf config.profile1 {
# Profile 1 config here
};
profile2:
config = lib.mkIf config.profile2 {
# Profile 2 config here
};
And so on | 01:33:16 |
| Infinidoge 🏳️⚧️ | Matrix, why must you pain me | 01:33:24 |
