!wfudwzqQUiJYJnqfSY:nixos.org

NixOS Module System

203 Members
48 Servers

Load older messages

SenderMessageTime
5 Jun 2026
@mattsturg:matrix.orgMatt 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
@mattsturg:matrix.orgMatt 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
@mattsturg:matrix.orgMatt Sturgeon check itself only doing isList pre-dates v2 checkAndMerge, though 15:03:30
@blokyk:matrix.orgzoë (@blokyk) hmmm ok in my real scenario i'm override a nonEmptyListOf's merge with mergeEqualOption, maybe that's why? 15:04:28
@blokyk:matrix.orgzoë (@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
@blokyk:matrix.orgzoë (@blokyk)ah yes that's why15:06:07
@mattsturg:matrix.orgMatt 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
@blokyk:matrix.orgzoë (@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
@blokyk:matrix.orgzoë (@blokyk)well, i'll try to figure out how to make it work with the non-merging merge; thanks!15:07:39
@mattsturg:matrix.orgMatt Sturgeon For a similar example, I had this abomination when trying to extend a submodule's merge function earlier today. 15:07:46
@mattsturg:matrix.orgMatt Sturgeon (aside: maybe it'd make sense for submoduleWith to accept an apply function, similar to an option's apply?) 15:08:31
@llakala:matrix.orgllakala

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:matrix.orgllakalaanyone have an idea why?15:23:01
@llakala:matrix.orgllakala logs are here 15:23:08
@llakala:matrix.orgllakala adding some tracing, putting _module.check first fixes the error - but it loses the stats gain 15:26:44
@mattsturg:matrix.orgMatt 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:matrix.orghsjobekiIf i had to guess, if you evaluate unmatchedDefns that changes lazyness15:34:35
@mattsturg:matrix.orgMatt Sturgeon Pretty sure config._module.check is first on purpose, to short-circuit non-lazy eval 15:34:36
@hsjobeki:matrix.orghsjobekiIn the new line you evaluate unmachtedDefns eagerly, where it was "lazy" before15:35:23
@llakala:matrix.orgllakalayeah i concur - i guess that's non-lazy lists for you15:35:42
@hsjobeki:matrix.orghsjobekiWhy did you want to change the order here? 15:36:44
@hsjobeki:matrix.orghsjobeki The logik was if !config._module.check we can short circuit 15:37:27
@hsjobeki:matrix.orghsjobeki * The logic was if !config._module.check we can short circuit 15:37:30
@hsjobeki:matrix.orghsjobekiSame for freeformType15:37:42
@llakala:matrix.orgllakalareasoning was that it's almost always empty15:37:57
@hsjobeki:matrix.orghsjobekiWe dont need to check unmatchedDefns if either of those is set.15:37:58
@llakala:matrix.orgllakalaand for submodules it has a big stats difference15:38:07
@llakala:matrix.orgllakala 
{
  "attrset": {
    "lookups": "-3.82%",
    "merges": "-2.8%",
    "mergeCopies": "-0.53%"
  },
  "list": {
    "concats": "-0.95%"
  },
  "parser": {
    "expressions": null
  },
  "memory": {
    "envs": "-1.79%",
    "list": "-0.81%",
    "sets": "-1.08%",
    "symbols": null,
    "values": "-1.48%",
    "total": "-1.32%"
  },
  "speed": {
    "primops": "-2.01%",
    "functionCalls": "-1.85%",
    "thunksMade": "-2.1%",
    "thunksAvoided": "-1.69%"
  }
}
15:38:18
@llakala:matrix.orgllakala * 
{
  "attrset": {
    "lookups": "-3.82%",
    "merges": "-2.8%",
    "mergeCopies": "-0.53%"
  },
  "list": {
    "concats": "-0.95%"
  },
  "parser": {
    "expressions": null
  },
  "memory": {
    "envs": "-1.79%",
    "list": "-0.81%",
    "sets": "-1.08%",
    "symbols": null,
    "values": "-1.48%",
    "total": "-1.32%"
  },
  "speed": {
    "primops": "-2.01%",
    "functionCalls": "-1.85%",
    "thunksMade": "-2.1%",
    "thunksAvoided": "-1.69%"
  }
}
15:38:27
@hsjobeki:matrix.orghsjobekiHm then it might be worth tracking down15:38:34

Show newer messages

Back to Room ListRoom Version: 10