Add nix_store_build_paths to libstore-c#15352
Add nix_store_build_paths to libstore-c#15352RossComputerGuy wants to merge 1 commit intoNixOS:masterfrom
Conversation
src/libstore-c/nix_api_store.cc
Outdated
| nix::to_json(json, result); | ||
| callback(userdata, result.path.to_string(store->ptr->config).c_str(), json.dump().c_str()); |
There was a problem hiding this comment.
Do we really want to operate on arbitrary json? Seems like we need a C API counterpart of the build result.
There was a problem hiding this comment.
I'm not sure why we would, we've always done JSON for this sort of thing afaik. I forget the exact reasoning but at least when I've worked with this through nixops4/nix-bindings-rust, having arbitrary JSON has made binding from Rust quite easy since serde is able to handle it. It also makes it easier to upgrade Nix and not have to change the bindings or C API.
There was a problem hiding this comment.
Dunno, the whole point of the C API is to provide an unambiguous and ABI stable efficient interface for accessing things. Adding JSON strings into the mix seems strange. JSON derivations are a separate thing since at some point those should stop changing...
There was a problem hiding this comment.
That is understandable and makes sense, though I'd like to see what others think who have also worked with the C API. Probably @roberth is good to bring in to discuss this.
RossComputerGuy
force-pushed
the
upstream-capi-build-paths
branch
from
ecfba2f to
bc9cdc0
Compare
2 participants
Motivation
Provides a more flexible way to build paths,
nix_store_build_pathscan take opaque paths. That means they're not a.drvfile, that makes this useful for fetching paths which have no.drvassociated with it.Context
Upstream
nix_store_build_pathsfrom DeterminateSystems#210 & sliced out of #14031Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.