| 17 Jun 2021 |
aaronjanse | Ah got it | 21:33:15 |
infinisil | Maybe Nix needs a separate call stack for user errors | 21:34:18 |
infinisil | Something like builtins.addErrorContext, but which is shown by default in case of throws and which isn't used by the language internals | 21:34:45 |
aaronjanse | Or perhaps Nix could default to showing explicitly-added context when there is a error | 21:38:54 |
infinisil | Hmm that sounds interesting | 21:40:29 |
infinisil | I wonder how the default errors would look then | 21:40:37 |
aaronjanse | I assume it would be similar to how they are now, except for a few added lines when an explicit addErrorContext is used | 22:46:38 |
aaronjanse | It seems helpful, since iirc nixpkgs uses it for some user-facing errors yet it's only visible in --show-trace, which has a lot more information than the user needs | 22:47:45 |
| 18 Jun 2021 |
Jan Tojnar | How does literalExample even work? | 09:30:59 |
Jan Tojnar | I mean how is ${pkgs.foo} kept literally instead of being interpolated? | 09:31:55 |
sterni | Jan Tojnar: it doesn't, you still need to escape stuff | 09:36:11 |
Jan Tojnar | Well, it seems to not be interpolated in the manual | 09:36:30 |
sterni | I think it just causes the documentation generator to wrap it as code instead of trying to render the value | 09:36:36 |
Jan Tojnar | so something must be reversing the interpolation | 09:36:43 |
Jan Tojnar | but I have been so far unable to find the code resoponsible | 09:37:02 |
sterni | Jan Tojnar: what are you referring to? I've never seen that | 09:37:33 |
Jan Tojnar | sterni (he/him): https://github.com/NixOS/nixpkgs/pull/127085/files#r652869810 | 09:38:21 |
Jan Tojnar | I have seen that few times | 09:38:28 |
Jan Tojnar | It definitely is interpolated when I view the value in the repl: (nixos {}).options.xdg.portal.wlr.settings.example | 09:38:55 |
Jan Tojnar | but in the manual, it is shown verbatim | 09:39:43 |
Jan Tojnar | the optionsXML here is already uniterpolated https://github.com/NixOS/nixpkgs/blob/dc24c0f7148db1fe36afd1df81fbb4bbc4e9941e/nixos/lib/make-options-doc/default.nix#L179 | 09:41:37 |
Jan Tojnar | Trying the following, it looks like the value is already passed uninterpolated to nixosOptionsDoc
--- a/lib/options.nix
+++ b/lib/options.nix
@@ -175,7 +175,10 @@ rec {
let
docOption = rec {
loc = opt.loc;
- name = showOption opt.loc;
+ name =
+ let
+ name = showOption opt.loc;
+ in if name == "xdg.portal.wlr.settings" then builtins.trace (opt.example).text name else name;
description = opt.description or (lib.warn "Option `${name}' has no description." "This option has no description.");
declarations = filter (x: x != unknownModule) opt.declarations;
internal = opt.internal or false;
| 09:56:35 |
Jan Tojnar | Oh, here it is https://github.com/NixOS/nixpkgs/blob/17bcbee9fa5aabb3e0b4015b71eb6578da2d6fe3/nixos/modules/misc/documentation.nix#L21-L40 | 10:20:11 |
sterni | ohhhhhh | 10:20:52 |
sterni | that is wild | 10:20:59 |
sterni | I wonder how hard that is on evaluation time of the manual? | 10:22:45 |
lunik1 | In reply to @buckley310:matrix.org
a module can be
{ lib, ... }:{ config = lib.mkMerge [ ]; }
I did this but I'm not sure how to access the resulting merged config as an attribute set? | 15:34:45 |
aaronjanse | In reply to @jtojnar:matrix.org I mean how is ${pkgs.foo} kept literally instead of being interpolated? Maybe it uses unsafeGetAttrPos? | 16:01:02 |
sterni | aaronjanse: no, it passes a package set of fake derivations to the modules where outPath = "${attr.path}", it seems | 16:19:51 |
sterni | see the snippet Jan linked | 16:19:55 |