| 17 Aug 2023 |
 @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 |
| @infinisil:matrix.org | cole-h: https://github.com/NixOS/ofborg/pull/649 | 14:33:31 |
| 19 Aug 2023 |
|  NinjaTrappeur changed their display name from NinjaTrappeur .: DECT 8711 to NinjaTrappeur. | 11:11:26 |
| 20 Aug 2023 |
|  Stéphan left the room. | 18:26:47 |
| 21 Aug 2023 |
| @infinisil:matrix.org | In reply to @infinisil:matrix.org
What would be the best way to integrate this into ofborg? I've thought of some options:
- Just add the check here as a
nix-build, but then CI would be super slow when Rust needs to be built
- Same as 1, but only make it run on the master branch, therefore generally avoiding problems with rebuilds, and this check is only important for new packages, which generally don't have to go to staging anyways
- Same as 1, but don't use dependencies from current Nixpkgs to build the Rust program, instead do a
fetchTarball for the latest stable NixOS release, which should definitely have Rust cached
- Put the version of the Rust check program into ofborg itself, such that it's not influenced by anything going on in Nixpkgs. This is the fastest, but least flexible
I think I know what I'll do now: Write the program in Rust, check the source into Nixpkgs (it's internal to Nixpkgs), make it be built by Hydra, make the nixpkgs-unstable channel be blocked on it succeeding to build on x86_64-linux, then have a GitHub Actions workflow fetch it from the nixpkgs-unstable channel and run it on every PR | 22:31:56 |
| @infinisil:matrix.org | The trade-off here is that I need a separate initial PR to get the program building in Hydra and wait for a nixpkgs-unstable update before it can actually start running in CI, but that's fine | 22:32:51 |
| @infinisil:matrix.org | From then on it should be very smooth sailing, could use any sort of caching in GitHub actions to speed it up further too (static build + github's action cache should be really fast) | 22:34:24 |
| @infinisil:matrix.org | So, no need to touch ofborg :) | 22:35:08 |
| @infinisil:matrix.org | (and I think this would be a great general pattern we should use more often) | 22:35:33 |
