If we extract the NAR above, we see it’s just the contents of our Nix derivation.
Nit: I think it’d be more correct to say that it contains the outputs of our Nix derivation.
There’s also the spec in Cachix API, but I have yet to tag the endpoints so it’s clear what’s Cachix specific.
With CA derivations there is also a new route: nix-serve/server.cpp at a359b74b6e7dabfd10a0bd3b7efa1e2f494fb485 · Mic92/nix-serve · GitHub
Thanks, adding it to the API specification.
It’s JSON but everything else is text/plain ? Weird.
I’m not familiar with
.do what’s the variable in the route ?
nix-serve seems to be missing the ability to handle compression also when I checked the routes.
In this implementation also
plain/text is used: ca-derivations support by regnat · Pull Request #21 · edolstra/nix-serve · GitHub
I think nix does not care about the content type, but it actually returns json, which is why I changed in my fork. The schema is described here: nix/realisation.cc at d581129ef9ef5d7d65e676f6a7bfe36c82f6ea6e · NixOS/nix · GitHub
I have not tested properly this part as it is still broken for me. I will can share what it outputs once I get the nix part to work
I’d like to point out that an old version of the Nix manual does explain how the binary cache works, but I guess it was removed for reasons like unwilling to guarantee stability of the API. You can still find it on: https://releases.nixos.org/nix/nix-1.11.9/manual/index.html#idm140737316141296
Wow that’s a great piece of the manual. Ashame it was removed.