| 10 Jun 2026 |
 Matt Sturgeon | PR's been sat ready for review, waiting on discussion around the proposed micro-optimisations 😉 | 12:42:36 |
| Matt Sturgeon | At this point I wouldn't be opposed to landing it as-is, taking any small performance hit for now, and dealing with optimisations in their own PRs | 12:44:25 |
 hsjobeki | I wouldnt worry to much about the small performance differences.
My biggest concern is that we had to fix github.com/NixOS/nixpkgs/pull/525738
And there might be more out there , not in nixpkgs | 12:46:48 |
| hsjobeki | * I wouldnt worry to much about the small performance differences.
My biggest concern is that we had to fix https://github.com/NixOS/nixpkgs/pull/525738
And there might be more out there , not in nixpkgs | 12:47:01 |
| Matt Sturgeon | Honestly, my view on that is that every "add V2 support to X type" will break some ad-hoc check or merge override. And that there's not much we can do about finding every single case, other than look for them with grep and evals, and wait for bug reports about the rest. | 12:49:27 |
| Matt Sturgeon | How did you handle this on the original "add V2 to most core types" PR? | 12:50:42 |
 toonn | I don't think nullOr having merge.v2 would help with my particular problem. This is a situation where there's an override dependent on another option. So whether or not the option is required depends on the value of the other option. | 12:51:23 |
| hsjobeki | So: Your "isRequired" does not depend on whether the option is defined at all? | 12:54:16 |
| hsjobeki | * So: your "isRequired" does not depend on whether the option is defined at all? | 12:54:33 |
| Matt Sturgeon | Yes, you can only evaluate isDefined for a given module graph. If you add more modules (e.g. modules that define the module, directly or indirectly) then you will get a different result. | 12:54:52 |
| Matt Sturgeon | * Yes, you can only evaluate `isDefined` for a given module graph. If you add more modules (e.g. modules that define the option, directly or indirectly) then you will get a different result. I think that's intuitive? | 12:55:23 |
| hsjobeki | Surprisingly few reports happened ^^ and we touched basically all composition types | 12:55:43 |
| toonn | Yes, we're talking about a specification that tells a user ahead of time what options they need to supply and what options they can supply. | 12:59:00 |
| Matt Sturgeon | In reply to @hsjobeki:matrix.org
Surprisingly few reports happened ^^ and we touched basically all composition types Adding v2 to one type is inherently lower risk than adding it to almost all composable types. I'd say we take the same "what will be will be" approach in all "add v2" PRs; in my view you've already gone above and beyond by finding the displayManager issue. | 13:00:18 |
| Matt Sturgeon | In reply to @toonn:matrix.org
Yes, we're talking about a specification that tells a user ahead of time what options they need to supply and what options they can supply. It sounds like you're trying to compute a concept that doesn't exist in the module system.
You can approximate it, with isDefined on a base module eval; i.e. an eval without user-defined modules (which is what getSubOptions provides).
But if you consider "is defined depends on other conditional definitions", you cannot evaluate "is sometimes required" from a single eval. We usually rely on option-docs to convey those kinda conditional and situational relationships.
At the end of the day, all you can compute is "for this module graph, is X option defined". Typically, docs use a base module graph without user definitions, and configs use an extended graph with user definitions. | 13:05:39 |
| hsjobeki | I'd say i'm leaning towards:
the nullor-hoist-v2-check variant
what about llakala ?
https://github.com/NixOS/nixpkgs/pull/525519
| 13:14:13 |
| toonn | Yeah, that's what I thought. It's unfortunate because it means either being too strict in what I accept or not strict enough. Recomputing at a later time is possible but doesn't help with the fact that at any time the result is either too strict or not strict enough. | 13:18:55 |
 llakala | is the hoisting just readability compared to nullor-b? | 13:24:42 |
| Matt Sturgeon | Fractionally lower lookups, even more fractionally higher everything else IIRC | 13:25:46 |
| llakala | im fine with nullor-v2 or the hoist version | 13:27:46 |
| llakala | to be clear I doubt all this will have that bad of a real-time diff | 13:27:57 |
| llakala | and I've got a lot of other PRs up to hopefully alleviate it | 13:28:07 |
| llakala | i just wanted to minimize the regression and I think we've done that well enough | 13:28:27 |
| llakala | review on https://github.com/NixOS/nixpkgs/pull/517881 and https://github.com/NixOS/nixpkgs/pull/528010 would be great btw | 13:34:18 |
| hsjobeki | Will try to do the first one later | 13:46:47 |
| hsjobeki | llakala: you can also review this one :
https://github.com/NixOS/nixpkgs/pull/510713 | 13:59:04 |
| hsjobeki | Removes 3% opUpdates | 13:59:55 |
| Matt Sturgeon |
+12-153
🚀 I was actually reading the defaultFunctor code the other day to try and understand whether symmetrical addCheck and postTransform type-merging was possible (spoilers: no). It should be much more understandable with wrapped removed!
| 14:05:53 |
| 12 Jun 2026 |
|  Sapii/Saperson changed their display name from Sapii to Sapii/Saperson. | 01:24:37 |
| 13 Jun 2026 |
|  klea (she/her) joined the room. | 21:44:06 |
