| 5 Jun 2026 |
 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 |
 hsjobeki | If i had to guess, if you evaluate unmatchedDefns that changes lazyness | 15:34:35 |
| Matt Sturgeon | Pretty sure config._module.check is first on purpose, to short-circuit non-lazy eval | 15:34:36 |
| hsjobeki | In the new line you evaluate unmachtedDefns eagerly, where it was "lazy" before | 15:35:23 |
| llakala | yeah i concur - i guess that's non-lazy lists for you | 15:35:42 |
| hsjobeki | Why did you want to change the order here? | 15:36:44 |
| hsjobeki | The logik was if !config._module.check we can short circuit | 15:37:27 |
| hsjobeki | * The logic was if !config._module.check we can short circuit | 15:37:30 |
| hsjobeki | Same for freeformType | 15:37:42 |
| llakala | reasoning was that it's almost always empty | 15:37:57 |
| hsjobeki | We dont need to check unmatchedDefns if either of those is set. | 15:37:58 |
