| 5 Jan 2025 |
 emily | not that that should block incremental improvements in the meantime | 18:59:10 |
| emily | the hook seems like a good idea to me | 19:00:06 |
 connor (burnt/out) (UTC-8) | Oh you mean like structured JSON logging? I had tried to do stuff with the @nix formatting but I didn’t like what the result looked like and templating JSON from bash is tricky, so it just does plain text logging | 19:00:07 |
| emily | not structured per se | 19:00:28 |
| emily | just using @nix to signal a log level and message, so that nix build/nix log can show your desired logging level without needing a rebuild | 19:00:43 |
| emily | that would require getting changes in Nix though 🙃 | 19:00:53 |
| emily | this came up back when we had really verbose logging for hooks on by default | 19:01:01 |
| emily | which is useful to debug things without rebuilding the world but was really unpleasant most of the time | 19:01:10 |
| emily | basically ideally we shouldn't be deciding to filter at build time but on the viewing end | 19:01:23 |
| emily | (except for things so spammy that they might slow down a build appreciably to even shove through a pipe) | 19:01:35 |
| connor (burnt/out) (UTC-8) | Ahhhhh yeah! It’d be particularly nice if there were an option to always capture the most verbose output in a build log file on disk (which could be compressed) while the content printed out was filtered for the current log level | 19:02:21 |
| connor (burnt/out) (UTC-8) | lol agreed took me longer to type out the same thing | 19:02:50 |
| emily | right. | 19:02:50 |
| emily | I think most of the pieces are there already, it just needs implementing | 19:03:02 |
| emily | here's some historical context | 19:03:33 |
| emily | https://github.com/NixOS/nixpkgs/issues/328229
https://github.com/NixOS/nixpkgs/pull/331560
https://github.com/NixOS/nixpkgs/pull/331794 | 19:03:51 |
| emily |
Both projects support structured output logging (through the @nix { "action": "msg", "level": "[0-7]", "msg": "some message" } special messages output to the file descriptor that $NIX_LOG_FD points to.
| 19:04:46 |
| emily | IMO this would be very high value if someone managed to get it into Nix/Lix | 19:05:10 |
| emily | because rebuilding with a higher NIX_DEBUG just to check some build issue sucks | 19:05:19 |
| emily | we would have to check how much overhead even processing/storing/discarding the logs would be and there's even considerations like Hydra's web interface, but it would be really great | 19:05:39 |
| emily | anyway, like I said enough of a task that it shouldn't block incremental improvements :) | 19:05:47 |
| emily | but I don't think it would be an immense amount of implementation work and the benefits would be huge | 19:06:02 |
| connor (burnt/out) (UTC-8) | Wouldn’t that change need to be backported through Nix 2.3? | 19:48:29 |
| connor (burnt/out) (UTC-8) | * Wouldn’t such changes need to be backported through Nix 2.3? | 19:49:40 |
| emily | I don't think so – spammy build output isn't a compatibility break | 19:50:36 |
| emily | (but we should bump minver to 2.18 anyway, it was discussed on a recent structured attributes PR…) | 19:50:46 |
| 6 Jan 2025 |
| emily | how does stdenvNoCC get defined? I see a bunch of stdenvNoCC =s, of course, but I can't tell where the magic to stop it having a cc happens. | 18:40:34 |
| emily | (in particular, I want to know one can condition the extraBuildInputs on cc-ness) | 18:41:32 |
 Artturin | https://github.com/NixOS/nixpkgs/blob/a8af4a1033a3ab6d14d37731512ecd8bbf39c2b9/pkgs/top-level/stage.nix#L54
https://github.com/NixOS/nixpkgs/blob/a8af4a1033a3ab6d14d37731512ecd8bbf39c2b9/pkgs/top-level/stage.nix#L148
https://github.com/NixOS/nixpkgs/blob/a8af4a1033a3ab6d14d37731512ecd8bbf39c2b9/pkgs/top-level/stage.nix#L354 | 19:46:03 |
| emily | thanks | 19:47:57 |
