| 7 Feb 2026 |
 raitobezarius | (we being the Lix core team) | 20:05:50 |
 Lisanna | How are you envisioning that working? Will there be a different nix.conf setting for hooks that speak the RPC protocol? | 20:06:35 |
| raitobezarius | If you are familiar with how Snix works, we would fission the whole build subsystem into its own RPC boundary, so someone could tap into a library to spawn a build RPC component and bring their own scheduler logic | 20:07:18 |
| raitobezarius | It's already kinda possible to do something akin that by proxying Nix daemon protocol | 20:07:34 |
| raitobezarius | * It's already kinda possible to do something akin to that by proxying Nix daemon protocol | 20:07:43 |
| raitobezarius | (we would also use that work to enable better out-of-the-box scheduler logic, remote building and more) | 20:08:04 |
| raitobezarius | The remote building hook has been already subject to RPC-ification with Cap'n'Proto, so we are working towards slowly confirming our expectations for this architecture | 20:08:40 |
| Lisanna | I will take a look at the Snix implementation, I have not looked at it at all yet | 20:09:18 |
| raitobezarius | https://snix.dev/docs/components/overview/ | 20:09:29 |
| raitobezarius | They have cute figures | 20:09:31 |
| raitobezarius | https://snix.dev/docs/components/build/protocol/ is relevant too | 20:09:39 |
| Lisanna | ^-^ | 20:09:39 |
| Lisanna | so you would launch your custom builder as a standalone program, and it would then register itself as a builder through a library call? rather than being launched by the Lix cli or daemon directly? | 20:18:19 |
| raitobezarius | the deployment story is not totally hammered down, but a daemon frontend could receive build daemons URIs (remote or local), once you run a lix command that makes use of build, they would be sent to that daemon via RPC | 20:19:19 |
| raitobezarius | but yeah, in that context, Lix CLI or daemon wouldn't execve() a build component | 20:19:52 |
| raitobezarius | it would be delegated | 20:19:55 |
| Lisanna | alright | 20:20:02 |
| Lisanna | I'll keep watch for progress on this front, and see about adding a mode to my program for this kind of usage | 20:21:15 |
| Lisanna | is there an issue tracking it I can follow? | 20:22:28 |
| raitobezarius | https://git.lix.systems/lix-project/lix/issues/911 | 20:23:49 |
| raitobezarius | for build-hook | 20:23:53 |
| raitobezarius | i think we may remove it only once we have hit a blocker due to it OR we have replaced it | 20:24:15 |
| raitobezarius | the full core team is usually at https://zulip.lix.systems/#narrow/channel/9-Store to discuss these topics on higher bandwidth | 20:24:57 |
| Lisanna | Like the linked issue mentions, I've considered reimplementing this as a custom store plugin, but that presents complications for this particular use-case. I think you'd have to manually retrieve the build result from the custom store after the build completes, because it won't be copied back to the local store automatically. Unless the remote's local store is on a shared filesystem, it would need to keep track of which node has which build result, which would be hard to do in-between invocations, potentially causing rebuilds or not being able to find the already built derivation. | 20:42:46 |
| raitobezarius | yeah, a store plugin is highly non trivial for what you are doing | 21:44:45 |
| raitobezarius | Changes performed | 23:14:06 |
 K900 | Someone do the dark souls image macro thing | 23:14:55 |
| K900 | I'm on my phone | 23:14:58 |
| raitobezarius | 
Download clipboard.png | 23:15:21 |
| K900 | Thank | 23:19:58 |
