| 9 Apr 2026 |
 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 |
| emily | picking the .drv out of temproots is my current best guess | 23:13:42 |
| Lisanna changed their profile picture. | 23:14:48 |
 Neil Mayhew | OK, that makes sense. There's no point in trying to make cachix use the lix-store library. However, what would happen if I use the current cachix (linked with nix-store) on a system that's using Lix as the nix-daemon? Would that break too? | 23:48:58 |
| 10 Apr 2026 |
 kfiz | Maybe, I only just learned that lix-daemon is only compatible with v1.35 of the nix-daemon protocol. If cachix relies on newer features this might break. | 00:47:26 |
| Neil Mayhew | Thanks, that's helpful and gives me something concrete to check | 00:48:30 |
| kfiz | Your welcome. see link to source from an earlier post. | 00:51:57 |
| Lisanna | If you're planning anything in the remote builder space, I'd be very interested to know btw ^^ I've been doing work on improving remote building in cppnix so always interested in seeing what other use cases people have | 01:33:59 |
| Lisanna | also, if y'all would like any help on that effort, I definitely have the time, unless you think it would be harder to split the work | 01:41:57 |
