griff
Separate core data types from daemon code?
I've been doing a lot of work on the JSON instances for Nix lately https://github.com/NixOS/nix/issues/13570. The daemon protocol is fairly saddled with back compat, but as these are mostly greenfield (and still experimental) I can make them match the data types we want better. (This is especially noticeable for Derivation, which I am continuing to overhaul.)
Do you think it would be possible to shuffle around the crates so that the core library did not contain the daemon protocol, and that was in a downstream library instead? I would like that, but I don't know whether orphan impl rules will get in the way or not.
(Also, +1 on the the new stuff being MIT.)
CC @mic92
Sorry you delayed reply.
I am not entirely sure what you are talking about here since Nix.rs at the moment has no relation to or direct integration with NixOS/nix that I am aware of.
That being said I am not against moving core types into its own crate if that is useful. The approach I was thinking of going for up till now was more features based like tokio where the crate comes with no features enabled by default and then you enable what you need.
I have spent some time refactoring, cleaning and moving code around so that things should now be more logically structured (at least there now is a logic) as well as cleaning up features and moving all the spread out daemon protocol quirks and stuff almost entirely into the daemon module (specifically the daemon::wire::serde module.
Let me know if that aproach is good enough for you (a daemon feature flag and all code living under the daemon module) or if you would still prefer a separate crate with just the core types.
Thanks @griff. Just got to be clear I was working with @mic92 a bit on https://github.com/nix-community/harmonia/tree/001-nixrs-base, and thinking about a world where the current daemon protocol is no longer the one and only protocol.
That is also the purpose of the nixrs-capnp crate. It is where I prototype an extendable Cap'n Proto interface for both the current daemon protocol but also for how would a better protocol look like that takes advantage of the unique qualities of capnp like pipelining, streaming, capability interfaces and persistence of those interfaces. It is very experimental and might turn out to have been full of bad ideas that take the metaphor too far or makes it too slow.
My current attempt at something slightly better is in this schema: https://github.com/griff/Nix.rs/blob/main/nixrs-capnp/schema/nixrs/nixrs.capnp Which I have implemented and use in another prototype for a NixOS machine controller.