Properly store the outputs of CA derivations #4315
Closed
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.
For each “known” derivation output, store:
(morally what we want is two families of mappings: One mapping
unresolved derivations to their resolved version and one mapping
resolved derivations to their output path, but it's both simpler and
more efficient to combine them)
This comes with a set of needed changes:
drv-output-info
module declaring the types needed for describingthese mappings
Store::registerDrvOutput
method registering all the needed informationsabout a derivation output (also replaces
LocalStore::linkDeriverToPath
)Store::queryDrvOutputInfo
method to retrieve the informations for aderivations
This introcudes some redundancy on the remote-store side between
wopQueryDerivationOutputMap
andwopQueryDrvOutputInfo
.However we might need to keep both (regardless of backwards compat)
because we sometimes need to get some infos for all the outputs of a
derivation (where
wopQueryDerivationOutputMap
is handy), but all thestores can't implement it − because listing all the outputs of a
derivation isn't really possible for binary caches where the server
doesn't allow to list a directory.
For the local store, this uses a different db tables that will only be added to the schema if the
ca-derivations
experimental flag is on, meaning that people not using it won't be affected by the schema change