| 21 Nov 2025 |
|  isabel changed their profile picture. | 18:14:02 |
| 23 Nov 2025 |
 Matt Sturgeon | In nixvim, we recently used the new valueMeta to implement a warning that checks whether a submodule's sub-option is defined.
I was anticipating some breakage for users with an old/outdated nixpkgs revision pre-dating #391544. This seems to be the case for some users, however other users apparently have up-to-date inputs and are still reporting error: attribute 'valueMeta' missing.
Reports are in #3966 and #3960.
The nixvim test suite does not reproduce this in any of its test cases, most of which are module evals. The affected users have not yet provided complete reproducible examples.
One initial hypothesis is that type-merging (not definition merging) could be breaking v2 check+merge? E.g. if users declare programs.nixvim.* submodule options from outside the nixvim submodule, those declarations get merged into the option-type via type-merging. But that is pure conjecture at this point.
Before I dive too deep into investigating and trying to reproduce the issue, I was wondering if hsjobeki , Robert Hensing (roberth) , or anyone else familiar may have some insight or intuition?
| 23:02:23 |
 Robert Hensing (roberth) | Versions could explain it. Maybe add some asserts to catch that early? E.g. assert (attrsOf unspecified)?merge.v2; ... | 23:10:16 |
| Matt Sturgeon | Ah, that seems to be it.
A 25.05 (or otherwise pre-v2-checkAndMerge) host configuration importing a nixvim wrapper-module will use that host-configuration's lib as the basis for nixvim's "extended" lib:
https://github.com/nix-community/nixvim/blob/2606dc719488065e735ff0fc622d743566b21ad4/wrappers/_shared.nix#L73-L77
That should probably be changed to freshly import lib from our flake-locked nixpkgs revision, the same as we do when constructing pkgs.
| 23:48:16 |
| 24 Nov 2025 |
|  @whispers:catgirl.cloud joined the room. | 00:26:42 |
| @whispers:catgirl.cloud left the room. | 02:37:42 |
 nbp | What is this v2 about? | 13:37:23 |
| Matt Sturgeon | https://github.com/NixOS/nixpkgs/pull/391544 extended how option-types check and merge definitions. This means the merge function is responsible for checking and merging, and it is able to return additional metadata alongside the actual merged value. For submodules, this means we can introspect the actual submodule configuration, instead of just it's final config value. | 13:52:39 |
| nbp | Interesting …
This might help solve the issue that we have to forward per-submodule option definitions to the parent module. | 14:12:50 |
| nbp | I am not sure for the need of blending the check & merge functions, as we used to have this for submodules a while back, before people wanted to have freeform types. | 14:21:26 |
| nbp | we used to have extra values in submodules output at least. | 14:22:09 |
 n4ch723hr3r | whats the nixos version of home.file? i only find environment.etc | 16:23:07 |
| Robert Hensing (roberth) | Not sure I understand your problem description, but if you were adding options just to forward in-submodule metadata like options or _module to the parent, you could use valueMeta instead. | 16:46:50 |
| Robert Hensing (roberth) | Reason to merge the two operations is so that they can share computations. That's somewhat separate from the valueMeta addition | 16:47:37 |
 hsjobeki | I guess he is referring to seperate out the check, because freeformType is just calling merge without check | 16:48:01 |
| Robert Hensing (roberth) | They were combined into a single change to maximize the utility of having a v2 | 16:48:05 |
| Robert Hensing (roberth) | oh that... | 16:48:28 |
| hsjobeki | Though i am not sure what the benefit of merging without checking is. Checks are usually shallow and shouldnt change the lazyness. If the value is not of the expected type, merging it would also fail | 16:50:33 |
| Robert Hensing (roberth) | If you want merging without checking, you can still construct a type that achieves that | 16:51:02 |
| Robert Hensing (roberth) | But yeah, generally the check is simple because otherwise you're inducing unnecessary strictness, as in non-laziness | 16:51:36 |
| Robert Hensing (roberth) | => infinite recursions | 16:51:54 |
| hsjobeki | Do you suspect a breaking change in lazyness between just merge and checkAndMerge ? | 16:54:48 |
| hsjobeki | We dont have any reports, or at least i didnt get pinged in any issues regarding that. | 16:55:47 |
| n4ch723hr3r | do i have to use systemd.tmpfiles? | 16:56:55 |
| Matt Sturgeon | In reply to @n4ch723hr3r:nope.chat
do i have to use systemd.tmpfiles? This room is for discussing the module system itself, not NixOS and its options. You want https://matrix.to/#/!6oudZq5zJjAyrxL2uY:0upti.me | 17:16:25 |
 vivekanandan_ks | Hi All,
What do u all think about the flake-parts?
Is that somehow making the current modules system better?
Or it helps the current modules to be easy? | 17:59:32 |
| Matt Sturgeon | Flake-parts uses the module system to construct flake outputs. Just like how NixOS uses the module system to construct an OS, or Home Manager uses the module system to construct a user's profile.
I'm not sure what you're asking about how it interacts with "current" modules, or what you mean by "current" 🙂 | 18:20:35 |
| n4ch723hr3r | i think hes asking for an opinion about flake.parts | 18:43:44 |
| 26 Nov 2025 |
| hsjobeki | I'd say i don't have a general opinion.
If you develop a third party nix library that other people depend on every input that you have adds to their dependencies as well.
That is how flake dependencies behave. And everyone needs to pin nixpkgs-lib of flake-parts otherwise you get their version, which is an extra 50MB download.
Other than that if you are using it for your own project that doesn't have dependents it is in my opinion a good UX, which lets you leverage the module system to decompose the components of your flake. | 16:33:29 |
| Robert Hensing (roberth) | it now uses a small lib-only flake fwiw, but the override still makes sense to have | 16:39:27 |
