| 17 Aug 2023 |
|  @infinisil:matrix.org joined the room. | 21:51:30 |
| @infinisil:matrix.org | For RFC 140, CI should run a Rust program to check some property of the Nixpkgs tree for every PR | 21:54:48 |
| @infinisil:matrix.org | And it should fail if the check doesn't succeed | 21:55:25 |
| @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
| 22:01:48 |
| @infinisil:matrix.org | Actually 4. would be kind of nice because ofborg is a rust codebase too | 22:02:51 |
 cole-h | Is this program available anywhere yet? | 22:03:16 |
| cole-h | And what's the benefit of running it inside of ofborg, as opposed to, say, publishing a static Rust binary and pulling that in in some GitHub Action? | 22:04:07 |
| @infinisil:matrix.org | cole-h: Yeah: https://github.com/NixOS/nixpkgs/pull/237439/files#diff-6e9a910bb34a3e80b226fec620fb570f84328e04d16d479d106274a3a7d81b1c | 22:04:24 |
| cole-h | I could imagine a separate workflow file that would download the most recent release from NixOS/nixpkgs-checker-thingy and just run that, no need to worry about Rust rebuilds or ofborg integration | 22:04:58 |
| @infinisil:matrix.org | Hmm that could work too | 22:05:28 |
| @infinisil:matrix.org | I do really like 4. though, the check should be able to finish within a couple seconds that way. Comparatively GitHub Actions need to always download the thing first (can't use an existing /nix/store), set up the environment, etc. | 22:07:37 |
| @infinisil:matrix.org | And having to maintain another separate repository feels unnecessary | 22:08:15 |
| cole-h | If it's published as a static binary, there's no reason it should need a Nix store :P | 22:09:17 |
| @infinisil:matrix.org | Hmm true.. | 22:09:50 |
| @infinisil:matrix.org | It's really quite a Nixpkgs specific check, so it would fit into ofborg | 22:11:09 |
| @infinisil:matrix.org | Though tbh I never liked how Nixpkgs CI isn't declared in Nixpkgs itself, that's a good reason to not do that (nor any other separate repository) | 22:13:28 |
| @infinisil:matrix.org | If I had the time for it, I'd probably make ofborg be declared in an ofborg.nix file in the Nixpkgs root, where all checks would then be declared, and ofborg just has runners to make them efficient | 22:14:59 |
| @infinisil:matrix.org | E.g. for this RFC it would be a fairly generic check that "the Nix files in directory don't reference any files outside of it" | 22:15:32 |
| @infinisil:matrix.org | * If I had the time for it, I'd probably make ofborg be declared in an ofborg.nix file in the Nixpkgs root, where all checks would then be declared, and ofborg just has runners to make them efficient and turn them into github checks | 22:16:14 |
| cole-h | I'm mostly worried about how non-trivial it would be to integrate this into the current ofborg architecture.
If my option 5 (static binary published somewhere and pulled down by GHA) doesn't work out, I agree that option 4 is probably the next best. | 22:16:30 |
| cole-h | (To be clear: I'm not against the idea, but I'd much prefer not having to integrate it into ofborg.) | 22:18:00 |
| * @infinisil:matrix.org takes a closer look at ofborg | 22:19:11 |
| cole-h | (it's a mess) | 22:19:39 |
| @infinisil:matrix.org | Oh no | 22:19:46 |
| @infinisil:matrix.org | cole-h: Is there by chance an overview of all the parts involved somewhere? | 22:21:53 |
| cole-h | No, which is why it's a mess 😔 | 22:22:50 |
| cole-h | I'm not sure even I have an internalized map of the code | 22:23:26 |
| @infinisil:matrix.org | Hmm, do you have some plan for the future of ofborg? Or just maintenance mode until somebody writes something better? | 22:23:48 |
| cole-h | Mostly the latter, but I'm hoping I'll be that "somebody" as well, some day. (Maybe over the holidays I'll be able to dedicate some time to some overdue TLC.) | 22:26:04 |
| @infinisil:matrix.org | cole-h: Do you know where the complexity comes from? Is it just overengineered or are there actually tricky problems justifying it? | 22:30:03 |
