Add Store::buildPathsWithResults() #6221
Conversation
This function is like buildPaths(), except that it returns a vector of BuildResults containing the exact statuses and output paths of each derivation / substitution. This is convenient for functions like Installable::build(), because they then don't need to do another series of calls to get the outputs of CA derivations. It's also a precondition to impure derivations, where we *can't* query the output of those derivations since they're not stored in the Nix database. Note that PathSubstitutionGoal can now also return a BuildStatus.
edolstra
force-pushed
the
build-paths-with-results
branch
from
4e73a86 to
a4604f1
Compare
| void copyDrvsFromEvalStore( | ||
| const std::vector<DerivedPath> & paths, | ||
| std::shared_ptr<Store> evalStore); |
There was a problem hiding this comment.
I've been meaning to bring this up, can we call it "DrvStore" or similar in libstore? "Eval" is not a concept libstore should be aware of.
Also, can we do
| void copyDrvsFromEvalStore( | |
| const std::vector<DerivedPath> & paths, | |
| std::shared_ptr<Store> evalStore); | |
| void copyDrvsFromEvalStore( | |
| const std::vector<DerivedPath> & paths, | |
| Store & evalStore); |
I am hoping to cut down on the extraneous use of shared pointers (for ergonomics, more than efficiency).
There was a problem hiding this comment.
The only problem with that is that if you need a shared_ptr, it's hard to get it from a &.
|
@edolstra C.F. #4588 which was trying to get us closer to this this. @thufschmitt was worry about the serialization helpers trapping us WRT protocol versions, but after starting #1165 I decided it would be better to completely separate the legacy and new protocols so protocol version could be passed to the serializers, ameliorating that issue. If that sounds good, I'll do it after this lands. |
|
Alternatively we could serialize |
|
OK made the protocol versioning PR #6223
Sure, but I don't think it matters that much. JSON is nice enough, sure, but it doesn't save us from all versioning considerations, just adding new fields to objects. I am completely ambivalent. |
|
Thanks for making that change, excited for this! |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/tweag-nix-dev-update-27/18433/1 |
This function is like
buildPaths(), except that it returns a vector ofBuildResults containing the exact statuses and output paths of each derivation / substitution. This is convenient for functions likeInstallable::build(), because they then don't need to do another series of calls to get the outputs of CA derivations. It's also a precondition to impure derivations, where we can't query the output of those derivations since they're not stored in the Nix database.Note that
PathSubstitutionGoalcan now also return aBuildStatus.