| 17 Aug 2023 |
@infinisil:matrix.org | Maybe a permanent fix should be a way to only evaluate what changed for a PR | 23:29:27 |
piegames | Not sure to which extent this is feasible, given the spooky-action-at-a-distance nature of Nixpkgs fix points | 23:30:27 |
@infinisil:matrix.org | Nix does know which files get accessed underneath, see nix-build '<nixpkgs>' -A hello -v | 23:31:14 |
Lily Foster | In reply to @infinisil:matrix.org Maybe a permanent fix should be a way to only evaluate what changed for a PR So like only doing meta checks for outpaths that's changed, or something else? If so, meta could still be changed without outpath changing | 23:31:19 |
@infinisil:matrix.org | In reply to @infinisil:matrix.org Nix does know which files get accessed underneath, see nix-build '<nixpkgs>' -A hello -v Do this for each attribute once, then for each commit/PR, only re-evaluate it if the commit changed any of those paths | 23:31:57 |
Lily Foster | In reply to @infinisil:matrix.org Nix does know which files get accessed underneath, see nix-build '<nixpkgs>' -A hello -v Ah so which files Nix touches at all. That could maybe be done, but I'm not sure it would be faster.... | 23:32:21 |
@infinisil:matrix.org | This should definitely be faster! | 23:33:03 |
piegames | My gut feeling says one could still come up with edge cases where this does not work | 23:33:06 |
@infinisil:matrix.org | Changing files only leaf packages need will only cause those leaf packages to need re-evaluation | 23:33:16 |
@infinisil:matrix.org | In reply to @piegames:matrix.org My gut feeling says one could still come up with edge cases where this does not work Same, but I imagine we could implement a more resilient thing rather than nix-build -v :P | 23:33:40 |
Lily Foster | In reply to @infinisil:matrix.org This should definitely be faster! Okay I'll trust your claim then, I'm admittedly a bit tired and distracted right now and not fully grasping what you are suggesting 😅 | 23:33:52 |
@infinisil:matrix.org | Like, I know you can detect filesystem access with inotifywait or similar tools | 23:33:52 |
@infinisil:matrix.org | fuse filesystems work too | 23:34:01 |
@infinisil:matrix.org | I could probably come up with a hacky but reliable way to do that in a day | 23:34:30 |
piegames | This should be a proper Nix eval API instead then | 23:35:25 |
@infinisil:matrix.org | Yeah that would be nice too | 23:35:42 |
@infinisil:matrix.org | Related: https://github.com/NixOS/nix/pull/8699 | 23:35:52 |
@infinisil:matrix.org | That has a bunch of nice implications for Nix CI | 23:36:09 |
Lily Foster | Oh sweat, yeah. And stuff like nixd even | 23:36:22 |
Lily Foster | (and reduce some of the cross-language hacks I've seen to interface with the libs from rust and whatnot too) | 23:36:55 |
@infinisil:matrix.org | In reply to @infinisil:matrix.org I could probably come up with a hacky but reliable way to do that in a day Oh, problem: All packages need to evaluate all-packages.nix, so if you update that, all packages could've changed for all Nix knows | 23:38:43 |
@infinisil:matrix.org | RFC 140 unintentionally seems to help here | 23:39:04 |
@infinisil:matrix.org | cole-h: Anyways, regarding the RFC 140 CI check, I'll try to see how it could be integrated into ofborg. If it's easy I'll probably make a PR | 23:46:18 |
@infinisil:matrix.org | (as much as I want to help fixing ofborg, I can't always get stuck in rabbit holes!) | 23:48:17 |
@infinisil:matrix.org | * (as much as I want to help fixing ofborg, I can't always get stuck in rabbit holes! RFC 140 should get done first :)) | 23:48:33 |
@infinisil:matrix.org | I slowly get what you meant by ofborg being a mess | 23:52:40 |
@infinisil:matrix.org | It's like 10000 lines of uncommented random-looking code | 23:53:05 |
| 18 Aug 2023 |
@infinisil:matrix.org | cole-h: https://github.com/NixOS/ofborg/tree/cda5aa2ac77a70bb5660d8d5614a640aacbe7523/ofborg/src/tasks/eval looks like it was made to support non-nixpkgs repositories. Is ofborg actually used on non-nixpkgs repos? | 14:03:10 |
@infinisil:matrix.org | And if not, could I just send a refactoring that removes the generic code? | 14:03:26 |
cole-h | If it's only the refactoring in that PR, I'd be happy to take a look, sure! | 14:04:53 |