Parse deriving paths in DerivationOptions
#14506
Open
Conversation
This file contains hidden or 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
github-actions
bot
added
new-cli
Ericson2314
force-pushed
the
derivation-options-parse-paths
branch
from
b126d79 to
00d2bf9
Compare
This was referenced Nov 7, 2025
Member
Author
|
Ah it needs a daemon-version thing for that message. |
edolstra
reviewed
Nov 10, 2025
| bool ignoreSelfRefs = false; | ||
| std::optional<uint64_t> maxSize, maxClosureSize; | ||
|
|
||
| using DrvRef = nix::DrvRef<Input>; |
Member
There was a problem hiding this comment.
This is already giving me a headache... What is a DrvRef conceptually, and since when do output checks refer to anything other than store paths?
| * separately. That would be nice to separate concerns, and not make any | ||
| * environment variable names magical. | ||
| */ | ||
| template<typename Input> |
Member
There was a problem hiding this comment.
Input is a heavily overloaded term. What's the intended meaning of input here?
|
|
||
| /** | ||
| * A reference is either to a to-be-registered output (by name), | ||
| * or to an already-registered store object (by `Input`). |
Member
There was a problem hiding this comment.
Shouldn't Input be named StorePath then? And why does that need to be a template parameter?
|
🎉 All dependencies have been resolved ! |
xokdvium
reviewed
Nov 10, 2025
Ericson2314
force-pushed
the
derivation-options-parse-paths
branch
from
00d2bf9 to
4611d31
Compare
This is an example of "Parse, don't validate" principle [1]. Before, we had a number of `StringSet`s in `DerivationOptions` that were not *actually* allowed to be arbitrary sets of strings. Instead, each set member had to be one of: - a store path - a CA "downstream placeholder" - an output name Only later, in the code that checks outputs, would these strings be further parsed to match these cases. (Actually, only 2 by that point, because the placeholders must be rewritten away by then.) Now, we fully parse everything up front, and have an "honest" data type that reflects these invariants: - store paths are parsed, stored as (opaque) deriving paths - CA "downstream placeholders" are rewritten to the output deriving paths they denote - output names are the only arbitrary strings left Since the first two cases both become deriving paths, that leaves us with a `std::variant<SingleDerivedPath, String>` data type, which we use in our sets instead. Getting rid of placeholders is especially nice because we are replacing them with something much more internally-structured / transparent. [1]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ Co-authored-by: Sergei Zimmerman <[email protected]>
Ericson2314
force-pushed
the
derivation-options-parse-paths
branch
from
4611d31 to
81921d7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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 is an example of "Parse, don't validate" principle.
Before, we had a number of
StringSets inDerivationOptionsthat were not actually allowed to be arbitrary sets of strings. Instead, each set member had to be one of:a store path
a CA "downstream placeholder"
an output name
Only later, in the code that checks outputs, would these strings be further parsed to match these cases. (Actually, only 2 by that point, because the placeholders must be rewritten away by then.)
Now, we fully parse everything up front, and have an "honest" data type that reflects these invariants:
store paths are parsed, stored as (opaque) deriving paths
CA "downstream placeholders" are rewritten to the output deriving
paths they denote
output names are the only arbitrary strings left
Since the first two cases both become deriving paths, that leaves us with a
std::variant<SingleDerivedPath, String>data type, which we use in our sets instead.Getting rid of placeholders is especially nice because we are replacing them with something much more internally-structured / transparent.
Context
Progress on #13570
Depends on #14505
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.