!wfudwzqQUiJYJnqfSY:nixos.org

NixOS Module System

201 Members
46 Servers

Load older messages


SenderMessageTime
29 May 2026
@mattsturg:matrix.orgMatt Sturgeon *

so we may want to fix instances of nullOr being merged before merging this.

Interesting. Is there a test I can run that covers that? By "merged" do you mean the // { description, check } update?

Feels like that's related to the wider "addCheck is broken" issues exposed by v2 check+merge.
There is (Report error for unsupported t // { check = ...; }) that tries to warn when check is shadowed on a type that supports v2 check+merge, though. Did the warning not trigger on your example?

20:20:11
@mattsturg:matrix.orgMatt Sturgeon *

so we may want to fix instances of nullOr being merged before merging this.

Interesting. Is there a test I can run that covers that? By "merged" do you mean the // { description, check } update?

Feels like that's related to the wider "addCheck is broken" issues exposed by v2 check+merge.
There is report error for unsupported t // { check = ...; } that tries to warn when check is shadowed on a type that supports v2 check+merge, though. Did the warning not trigger on your example?

20:20:22
@mattsturg:matrix.orgMatt Sturgeon

Yeah, I agree on hot-code. But on "normal" code, I tend to favor legibility over mirco-optimisation.

Based on roberth's comment on your linked issue I'll keep your version, though:

I support removing these calls from lib and other hot paths.

20:24:11
@llakala:matrix.orgllakala

oh, i should've sent the error - yeah that's the error that triggered

 error: The option `services.displayManager.defaultSession' has a type `session name' that uses
       an ad-hoc `type // { check = ...; }' override, which is incompatible with
       the v2 merge mechanism.

       Please use `lib.types.addCheck` instead of `type // { check }' to add
       custom validation. For example:

         lib.types.addCheck baseType (value: /* your check */)

       instead of:

         baseType // { check = value: /* your check */; }

       Alternatively, this message may also occur as false positive when mixing Nixpkgs
       versions, if one Nixpkgs is between 83fed2e6..58696117 (Aug 28 - Oct 28 2025)
20:25:10
30 May 2026
@aktaboot:tchncs.deaktaboot joined the room.09:08:13
@alekshandru:matrix.orgAlexandru Caraus joined the room.14:42:56
31 May 2026
@613fd0ba9f744876:matrix.org@613fd0ba9f744876:matrix.org joined the room.15:42:01
@613fd0ba9f744876:matrix.org@613fd0ba9f744876:matrix.org left the room.15:45:02
@vandycarlos:matrix.orgvandycarlos changed their display name from vandycarlos to Vandy arlos.22:00:31
@vandycarlos:matrix.orgvandycarlos changed their display name from Vandy arlos to Vandy Carlos.22:00:39
5 Jun 2026
@blokyk:matrix.orgzoë (@blokyk) joined the room.14:41:30
@blokyk:matrix.orgzoë (@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
@blokyk:matrix.orgzoë (@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
@blokyk:matrix.orgzoë (@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
@mattsturg:matrix.orgMatt 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
@mattsturg:matrix.orgMatt 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
@mattsturg:matrix.orgMatt 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
@blokyk:matrix.orgzoë (@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:matrix.orgtoonn It delays it until use, rather than throw it away, no? 15:00:07
@blokyk:matrix.orgzoë (@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
@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

Show newer messages


Back to Room ListRoom Version: 10