| 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 |
| 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:
config = lib.mkIf config.profile1 {
# Profile 1 config here
};
profile2:
config = lib.mkIf config.profile2 {
# Profile 2 config here
};
And so on | 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:
config = lib.mkIf config.profile1 {
# Profile 1 config here
};
profile2:
config = lib.mkIf config.profile2 {
# Profile 2 config here
};
And so on | 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:
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: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 |
