| 11 Jun 2021 |
|  bryan joined the room. | 10:22:20 |
|  @b:chreekat.net left the room. | 10:25:08 |
|  t_unix joined the room. | 10:27:51 |
| t_unix | hi | 10:27:58 |
| t_unix | I'd like to output a multi line string that contains hash (#) characters. Like:
${if stdenv.targetPlatform.isAarch32 then ''
# some comment related to stuff below
...
''
| 10:29:58 |
| t_unix | is that correct? | 10:30:14 |
| t_unix | repl says it should be fine. Same result for using double quotes instead of two single quotes | 10:33:32 |
| bryan | The repl can be trusted :) | 10:36:34 |
 aaronjanse | In reply to @andrew:mtx.rew.la
right, but the issue isn't limited to pkgs, anything can be passed to a function, so we don't know the context in which the function is called without reading the module which calls it Yep. I hope to address this in nix-eval-lsp by remembering what arguments are passed to a function. On flakes NixOS, you'd then evaluate the flake's nixosConfiguration to get the pkgs argument cached. On non-flakes NixOS, you'd have an in-memory expression like import /etc/nixos/configuration.nix { pkgs = import <nixpkgs>; } that would tell nix-eval-lsp what the pkgs argument may be | 19:20:07 |
| aaronjanse | That should actually be straightforward to add to nix-eval-lsp. I just need to figure out the cause of some performance issues I was having | 19:21:14 |
 andrew | that good news, thanks aaronjanse | 19:28:11 |
| andrew | I ran into another issue, do you have thoughts on whether nix-eval-lsp will be able to handle getting the definition of x in (e.g.) pkgs.python3.withPackages (x:... | 19:29:51 |
| aaronjanse | Once I implement the above feature, it should be able to get the value of x and show where its value is defined (i.e. the part of the withPackages implementation that calls the lambda the user passes) | 19:31:01 |
| aaronjanse | It should also be able to do stuff like autocomplete within with x; inside that lambda | 19:31:18 |
| andrew | very cool, nix-eval-parser could have very many uses in the nix ecosystem | 19:59:20 |
| andrew | * very cool, nix-eval-parser could have quite a few uses in the nix ecosystem | 19:59:32 |
| aaronjanse | In reply to @andrew:mtx.rew.la
very cool, nix-eval-parser could have quite a few uses in the nix ecosystem Like nix-eval-lsp but as a Rust crate? | 20:05:27 |
| andrew | I was thinking things like an incremental evaluator, great debugging tool | 20:05:58 |
| aaronjanse | Either way, yeah I'm excited to see what stuff is now possible. I look forward to seeing what happens with https://github.com/nix-community/rnix-lsp/pull/38 | 20:06:22 |
| aaronjanse | In reply to @andrew:mtx.rew.la
I was thinking things like an incremental evaluator, great debugging tool That would be great | 20:06:38 |
 Jez (he/him) | Surely this means we're not that far off being able to rewrite the whole of nix in Rust? 😜 | 20:11:37 |
| andrew | aaronjanse: I hope they review it. Otherwise it might make sense to just merge rnix-lsp in | 20:11:52 |
|  nodeven joined the room. | 21:13:06 |
| nodeven changed their display name from node to nodeven. | 22:52:46 |
| 12 Jun 2021 |
 Jan Tojnar | aaronjanse: we could definitely use the evaluation for nixpkgs-hammering | 12:46:38 |
| 13 Jun 2021 |
|  yusdacra changed their profile picture. | 03:31:24 |
 nf | hm, { foo ? bar } @ args: doesn't reflect the default value in args.foo, is that a feature? | 16:40:42 |
| aaronjanse | I think that's intentional, although I'm not sure if everyone agrees on whether it's a feature :P | 16:45:35 |
| nf | yeah i guess both choices are equally valid | 16:46:18 |
|  NixCannon joined the room. | 23:26:59 |
