NixOS Module System | 205 Members | |
| 48 Servers |
| Sender | Message | Time |
|---|---|---|
| 8 Jun 2026 | ||
* I guess we could fix listOf by skipping if the elemType may contain any submodule, and use the elemType.check then. However, we should make sure the error message does not add more confusion. Such as complaining that this is not an enumerated value, while we expect a list of enumerated values. | 13:00:53 | |
* I guess we could fix listOf by skipping if the elemType may contain any submodule, and use the elemType.check otherwise. However, we should make sure the error message does not add more confusion. Such as complaining that this is not an enumerated value, while we expect a list of enumerated values. | 13:01:05 | |
| 22:31:59 | ||
| 9 Jun 2026 | ||
| 16:07:54 | ||
Hello, what do I have to do to get the mk... family of functions (mkMerge, mkIf, mkOveride, mkOrder, etc.) to work within a custom option type? I'm fairly certain my merge function just wraps around existing ones and yet all of them just come through in the output unchanged and I can't understand why | 16:12:39 | |
If I have a mkMerge at the level just above the option type then it all seems to work but anything further into it and it doesn't | 16:14:55 | |
| Do you have an example what your type is trying to do? | 16:15:20 | |
| 16:15:40 | |
| basically XML as Nix, where you can have lists of attrsets to define multiple of a node, and if a different option defines only one, I want it to handle that gracefully | 16:16:32 | |
| * basically XML as Nix, where you can have lists of attrsets to define multiple of a node, and if a different module defines only one, I want it to handle that gracefully | 16:17:53 | |
| A bit hard to tell from breifly reading. Usually you call mergeDefinitions loc type defs in your typeYou dont call the merge functions of other types. | 16:18:31 | |
| IIRC I based it off of what the merge functions for attrsOf and listOf do | 16:20:02 | |
Do you mean instead of (lib.types.attrsOf nodelike).merge loc ..., to do mergeDefinitons loc (lib.types.attrsOf nodelike) ...? | 16:21:18 | |
| Yes | 16:21:43 | |
| alright, I'll give that a try, thanks | 16:22:01 | |
| You need to pass the correct type to mergeDefinitions which will be used for merging the defs | 16:22:29 | |
| There are some more problems in your code.
| 16:26:03 | |
| Conceptually i think you shouldn probably reconsider if you need to use foldl' with head, tail on the defs | 16:27:18 | |
| * Conceptually i think you should probably reconsider if you need to use foldl' with head, tail on the defs | 16:27:23 | |
acc.type is determined by the first element? But definitions don't have a predictable/stable order | 16:29:33 | |
ah no acc.type is always attrs since the bug with typeOf h | 16:30:26 | |
| oh nice catch thanks | 16:38:51 | |
| alright unfortunately changing the calls to use mergeDefinitions did not change the outcome | 16:53:04 | |
| so I'm still doing something wrong here | 16:53:14 | |
mergeDefintions is definetly the right track; There might be other quirks | 16:53:48 | |
| 16:53:51 | |
| Can you give an example how the type should work ? | 16:55:37 | |
| What should the produced value look like? | 16:55:51 | |
| * What should the final value look like? | 16:56:01 | |
| It's essentially just deep-merging an attrset, except that, because this represents nodes like XML, there can be multiple instances of any key, therefore if one module defines a single instance of that key as a set, and another module defines multiple instances as a list, the result should be a list of all the definitions | 16:58:49 | |