Give queryPartialDerivationOutputMap an evalStore parameter
#8724
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It appeared in 8eb73a8 (by me!) without justification.
This makes it more useful. In general, the derivation will be in one store, and the realisation info is in another. This also helps us avoid duplication. See how `resolveDerivedPath` is now simpler because it uses `queryPartialDerivationOutputMap`. In NixOS#8369 we get more flavors of derived path, and need more code to resolve them all, and this problem only gets worse. The fact that we need a new method to deal with the multiple dispatch is unfortunate, but this generally relates to the fact that `Store` is a sub-par interface, too bulky/unwieldy and conflating separate concerns. Solving that is out of scope of this PR. This is part of the RFC 92 work. See tracking issue NixOS#6316
github-actions
bot
added
the
store
This was referenced Jul 20, 2023
Ericson2314
commented
Jul 20, 2023
Comment on lines
-1040
to
-1054
|
|
||
| if (!experimentalFeatureSettings.isEnabled(Xp::CaDerivations)) | ||
| return outputs; | ||
|
|
||
| auto drv = readInvalidDerivation(path); | ||
| auto drvHashes = staticOutputHashes(*this, drv); | ||
| for (auto& [outputName, hash] : drvHashes) { | ||
| auto realisation = queryRealisation(DrvOutput{hash, outputName}); | ||
| if (realisation) | ||
| outputs.insert_or_assign(outputName, realisation->outPath); | ||
| else | ||
| outputs.insert({outputName, std::nullopt}); | ||
| } | ||
|
|
||
| return outputs; |
There was a problem hiding this comment.
This code is local-store-agnostic, and thus moved out of here.
edolstra
approved these changes
Jul 21, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
This makes it more useful. In general, the derivation will be in one
store, and the realisation info is in another.
This also helps us avoid duplication. See how
resolveDerivedPathisnow simpler because it uses
queryPartialDerivationOutputMap. In #8369we get more flavors of derived path, and need more code to resolve them
all, and this problem only gets worse.
Context
The fact that we need a new method to deal with the multiple dispatch is
unfortunate, but this generally relates to the fact that
Storeis asub-par interface, too bulky/unwieldy and conflating separate concerns.
Solving that is out of scope of this PR.
This is part of the RFC 92 work. See tracking issue #6316
Checklist for maintainers
Maintainers: tick if completed or explain if not relevant
tests/**.shsrc/*/teststests/nixos/*Priorities
Add 👍 to pull requests you find important.