| 31 May 2026 |
|  @613fd0ba9f744876:matrix.org joined the room. | 15:42:01 |
| @613fd0ba9f744876:matrix.org left the room. | 15:45:02 |
|  Vandy Carlos changed their display name from vandycarlos to Vandy arlos. | 22:00:31 |
| Vandy Carlos changed their display name from Vandy arlos to Vandy Carlos. | 22:00:39 |
| 5 Jun 2026 |
|  zoë (@blokyk) joined the room. | 14:41:30 |
| zoë (@blokyk) | is there any reason why this check would pass?
nix-repl> (lib.types.listOf (lib.types.enum [])).check [ "hello" ]
true
(this is a minimal example but the original type is also just an enum, and the merging doesn't throw any errors at all)
i found this issue but i don't think that's related since it seems to be submodule- and oneOf-specific?
| 14:46:14 |
| zoë (@blokyk) | * is there any reason why this check would pass?
nix-repl> (lib.types.listOf (lib.types.enum [])).check [ "hello" ]
true
(this is a minimal example but the original type is also just an enum, and the merging doesn't throw any errors at all)
(also sorry if this isn't the place to ask noobish question like this, it seems like mostly technical discussion ;-;)
i found this issue but i don't think that's related since it seems to be submodule- and oneOf-specific?
| 14:53:12 |
| zoë (@blokyk) | * is there any reason why this check would pass?
nix-repl> (lib.types.listOf (lib.types.enum [])).check [ "hello" ]
true
(this is a minimal example but the original type is also just an enum, and the merging doesn't throw any errors at all)
i found this issue but i don't think that's related since it seems to be submodule- and oneOf-specific?
(also sorry if this isn't the place to ask noobish question like this, it seems like mostly technical discussion ;-;)
| 14:54:10 |
 Matt Sturgeon | types.enum's check is literally x: elem x values, so (lib.types.enum []).check "hello" should fail.
types.listOf's check just uses isList, without also checking all elemType.check. This laziness was introduced in https://github.com/NixOS/nixpkgs/pull/6794
| 14:57:57 |
| Matt Sturgeon | * types.enum's check is literally x: elem x values, so (lib.types.enum []).check "hello" should fail.
types.listOf's check just uses isList, without also checking all elemType.check. This laziness was introduced in https://github.com/NixOS/nixpkgs/pull/6794
(specifically https://github.com/NixOS/nixpkgs/commit/e4bc2592f3c5fa2f05484e7258f99ebb0507d304)
| 14:58:49 |
| Matt Sturgeon | * types.enum's check is literally x: elem x values, so (lib.types.enum []).check "hello" should fail.
types.listOf's check just uses isList, without also checking all elemType.check.
This laziness was introduced in https://github.com/NixOS/nixpkgs/pull/6794
(specifically https://github.com/NixOS/nixpkgs/commit/e4bc2592f3c5fa2f05484e7258f99ebb0507d304)
| 14:59:07 |
| zoë (@blokyk) | is it also supposed to do that during merging? this really feels like a bug, or at least a gigantic footgun if listOf throws away any further typecheck ^^; | 14:59:41 |
 toonn | It delays it until use, rather than throw it away, no? | 15:00:07 |
| zoë (@blokyk) | personally in my case it just ignores it if i'm not mistaken. (i'll go check with my non-reduced example but i'd be surprised if it's different) | 15:00:49 |
| Matt Sturgeon | Hard to tell from skim-reading the merge function, but it looks like it is delegating checking & merging to the elemType and should surface type errors.
It's possible that there's a v1/v2 checkAndMerge interface bug though, e.g. if the outer or inner type is using the v1 interface and the other part is using v2? | 15:02:11 |
| Matt Sturgeon | * Hard to tell from skim-reading the merge function, but it looks like it is delegating checking & merging to the elemType and should surface type errors.
It's possible that there's a v1/v2 checkAndMerge interface bug though, e.g. if the outer or inner type is using the v1 interface and the other part is using v2? | 15:02:40 |
| Matt Sturgeon | check itself only doing isList pre-dates v2 checkAndMerge, though | 15:03:30 |
| zoë (@blokyk) | hmmm ok in my real scenario i'm override a nonEmptyListOf's merge with mergeEqualOption, maybe that's why? | 15:04:28 |
| zoë (@blokyk) | * hmmm ok in my real scenario i'm override a nonEmptyListOf's merge with mergeEqualOption (so that lists don't get merged), maybe that's why? | 15:04:42 |
| zoë (@blokyk) | ah yes that's why | 15:06:07 |
| Matt Sturgeon | If you're shadowing the merge attribute, then you're also removing any "delegate to elemType" logic unless your replacement merge itself delegates to the original merge. | 15:06:11 |
| zoë (@blokyk) | ah, i assumed mergeEqualOption would look at the original type but now that i check it doesn't take any argument so it obviously can't know the original type | 15:07:00 |
| zoë (@blokyk) | well, i'll try to figure out how to make it work with the non-merging merge; thanks! | 15:07:39 |
| Matt Sturgeon | For a similar example, I had this abomination when trying to extend a submodule's merge function earlier today. | 15:07:46 |
| Matt Sturgeon | (aside: maybe it'd make sense for submoduleWith to accept an apply function, similar to an option's apply?) | 15:08:31 |
 llakala | i have this diff to lib/modules.nix, but somehow this is causing the manual to fail to build:
diff --git a/lib/modules.nix b/lib/modules.nix
index 8c397caf7012..6c70a3ed8587 100644
--- a/lib/modules.nix
+++ b/lib/modules.nix
@@ -305,7 +305,7 @@ let
recursiveUpdate freeformConfig declaredConfig;
checkUnmatched =
- if config._module.check && config._module.freeformType == null && merged.unmatchedDefns != [ ] then
+ if merged.unmatchedDefns != [ ] && config._module.check && config._module.freeformType == null then
let
firstDef = head merged.unmatchedDefns;
baseMsg =
| 15:22:01 |
| llakala | anyone have an idea why? | 15:23:01 |
| llakala | logs are here | 15:23:08 |
| llakala | adding some tracing, putting _module.check first fixes the error - but it loses the stats gain | 15:26:44 |
| Matt Sturgeon | * aside: maybe it'd make sense for submoduleWith to accept an apply function, similar to an option's apply?
EDIT: https://github.com/NixOS/nixpkgs/pull/528474 | 15:32:53 |
