| 17 Apr 2024 |
 nbp | https://www.youtube.com/watch?v=lw7PgphB9qM ibizaman
https://www.youtube.com/watch?v=-Bfo3Byjwyg djacu | 09:00:25 |
| nbp | {} should be the smallest module possible, if I do not make any mistake. | 09:03:49 |
| nbp | djacu: That might be one of the most in-depth module presentation I've seen which does not present mkIf. | 09:44:36 |
| nbp | In reply to @infinidoge:matrix.org
I need to figure out a better way to test module stuff than shoving it in my NixOS configuration and opening the flake repl The module system has its own test suite under nixpkgs/lib/tests, the modules directory contains tons of tiny modules, and the modules.sh combine them in various way to check for the expected outcomes. | 10:29:33 |
 Robert Hensing (roberth) | In reply to @lorenzleutgeb:matrix.org
Hey! I have a question regarding the module system and/or generation of docs: How do I generate docs for a particular set of modules, i.e. all options defined in the modules from myservice.nix and myprogram.nix, only? Using baseModules = [] won't work, because my modules use options from NixOS. If that's not possible I run pkgs.nixosOptionsDoc for all modules and filter afterwards. Then the question arises how do I get a list of option names defined in a given module? Is that possible? As a last resort I would have to manually couple each module with some filtering expression.
infinisil pointed me at this comment, which helps, but still requires some external source of option names, e.g. I would have to know "services.maubot", and cannot start from maubot.nix, for which I don't care which option names it defines.
Sounds like what the flake.parts site is doing. It's currently a single evaluation with everything loaded at once, and then split out with this logic: https://github.com/hercules-ci/flake.parts-website/blob/af75b73a9cb306da0789bfd326e214c6103fd646/render/render-module.nix#L81 | 11:33:32 |
| Robert Hensing (roberth) | Would be good to make this kind of logic part of the module system proper. I'd like for something like that to be available in the module system library, and if someone wants to take that code and add tests, that'd be fine with me | 11:36:12 |
 Lorenz Leutgeb | In reply to @roberthensing:matrix.org
Sounds like what the flake.parts site is doing. It's currently a single evaluation with everything loaded at once, and then split out with this logic: https://github.com/hercules-ci/flake.parts-website/blob/af75b73a9cb306da0789bfd326e214c6103fd646/render/render-module.nix#L81 Looks like you are processing all (many, in my case including all of NixOS) options at once, and are then only filtering the result. This requires some "external data" (=the criteria for the filter). I ended up doing something similar: Couple every path of a file that defines a module with a regex that matches the options I expect to extract from it. Both our solutions are quite easy to implement, but what I was asking for goes a little further, i.e. to let the module system expose such filtering possibility. | 11:42:16 |
| Robert Hensing (roberth) | Seems we're asking for the same thing then :) | 11:54:45 |
 ibizaman | nbp well, congrats! Because it’s a damn good system indeed! :clap: | 14:00:26 |
| ibizaman | In reply to @infinidoge:matrix.org
I need to figure out a better way to test module stuff than shoving it in my NixOS configuration and opening the flake repl In my repo I’m having module tests (example) with evalModule and integration tests (example) with nixosTests and it’s all run together with flake checks. | 14:06:08 |
| ibizaman | In reply to @nbp:mozilla.org
https://www.youtube.com/watch?v=lw7PgphB9qM ibizaman
https://www.youtube.com/watch?v=-Bfo3Byjwyg djacu If you prefer a written version of the talk (which is not cut at the end) you can read here :) https://shb.skarabox.com/contracts.html | 14:08:07 |
 Infinidoge | In reply to @ibizaman:matrix.org
In my repo I’m having module tests (example) with evalModule and integration tests (example) with nixosTests and it’s all run together with flake checks. I more so mean ad-hoc testing of random module things, as opposed to proper module tests, however that is something I should also do | 14:17:03 |
| ibizaman | In reply to @infinidoge:matrix.org
I more so mean ad-hoc testing of random module things, as opposed to proper module tests, however that is something I should also do Ah I see. The only other example I can offer is related to testing functions like here. That being said, it’s also written tests. I can’t think of an intermediate way between this and load in the repl, even outside of nix modules. | 14:20:17 |
| Infinidoge | I think me using the word 'testing' is too loaded of a term lol | 14:23:04 |
| Infinidoge | I just mean messing around like you would with a repl :) | 14:23:28 |
| Infinidoge | It's just that defining and working with modules in the repl gets a bit annoying so I usually shove it in my NixOS configuration and let that eval the module | 14:24:04 |
