| 9 Apr 2026 |
 piegames | The status is please hold the line | 17:47:14 |
| piegames | Should be all set up within the next 6 months | 17:47:27 |
| piegames | Current work status is we have some internal protocols running on Capnproto already, but the main protocols need an interop story and everything's FUBAR and the person driving this got a bit burnt working on it and is currently taking a little break to recover. | 17:49:25 |
 blitz | That's fair | 18:00:51 |
| blitz | So shelling out it is 😅 | 18:01:15 |
 Yureka (she/her) | you could also directly implement the existing nix daemon protocol | 18:02:11 |
| Yureka (she/her) | or whatever version of it | 18:02:41 |
| Yureka (she/her) | https://codeberg.org/gorgon/gorgon/src/branch/main/nix-daemon | 18:04:56 |
| Yureka (she/her) | https://git.snix.dev/snix/snix/src/branch/canon/snix/nix-daemon | 18:04:58 |
| Yureka (she/her) | here are two implementations of it in rust. neither of them support getting NARs out of the nix store but the author of the gorgon one wasn't opposed to adding that | 18:05:26 |
| Yureka (she/her) | Redacted or Malformed Event | 18:05:38 |
| blitz | Will check. | 18:21:00 |
 neobrain | Is there a recommended way of implementing nix-based tooling? For example, say I wanted to generate and build a nix expression without relying on cppnix or lix specifically being installed on the system.
Presumably talking to the daemon would be preferred for that? And if yes, what's the typical communication protocol? (Do I pull in a library or do I just, like, open a Unix socket or something?) | 18:36:35 |
 K900 | The daemon doesn't do eval | 18:43:49 |
| K900 | Only the clients do | 18:43:53 |
| neobrain | oh right... so I would have to pull in something like snix to evaluate the expression, and then request the daemon to realize the evaluated expression? And creating an out-link (with a GC root) would be a client-task again presumably that I just can't really abstract over at all?
(Trying to get my terminology in line here) | 18:58:32 |
| neobrain | Interesting, looking at the unstable nix C API, there's apparently a plugin interface too. That might be suitable for the particular type of tooling I'm looking into atm | 19:02:38 |
| piegames | I think so, yes | 19:09:39 |
| K900 | Note that the snix evaluator can't evaluate nixpkgs fully correctly still afaik | 19:14:53 |
| neobrain | mhm relying on the command-line interface doesn't sound so bad now after all :( | 19:33:11 |
 @rosssmyth:matrix.org | I think it can eval some subset of nixpkgs. I remember someone building firefox and the Linux kernel successfully | 19:50:22 |
| @rosssmyth:matrix.org | Unsure what you are doing exactly, but you can check this out
https://github.com/Rucadi/njq | 19:51:54 |
| neobrain | Nice, will take a look thanks! I was mainly curious about the options. For the specific tool I have in mind atm it seems just using the CLI is best | 20:00:48 |
| neobrain | (the expression to evaluate is basically just pkgs.dockerTools.pullImage bundled with a shell script, so not exactly worth pulling in an entire evaluator for :D) | 20:02:46 |
|  Lisanna changed their profile picture. | 21:59:37 |
| Lisanna changed their profile picture. | 22:00:54 |
| Lisanna changed their profile picture. | 22:02:04 |
| Lisanna changed their profile picture. | 22:12:21 |
 nikstur | Super exited for this! I think this will be the game changer for building out Remote Builders and CI | 23:03:06 |
 emily | what's the current most least uncursed way of going from a build's PID/UID to the .drv it's building? | 23:07:58 |
