-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lib/types: Introduce types.unconditional #160491
base: master
Are you sure you want to change the base?
Conversation
Allows replacing `types.lazyAttrsOf elemType` with `types.attrsOf (types.unconditional elemType)`. Also works with lists: `types.listOf (types.unconditional elemType)`.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/tweag-nix-dev-update-25/18003/1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get this in while we wait for NixOS/nix#4090? I think this is a welcome simplification with no downsides.
@@ -151,9 +151,12 @@ rec { | |||
# issue deprecation warnings recursively. Can also be used to reuse | |||
# nested types | |||
nestedTypes ? {} | |||
# Whether `mkIf` assignments can cause the definiton to be optional in | |||
# the parent option. If `processed` is false, this is implicitly false too |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
processed
does not seem to have survived, whatever it was
isDefined = defsFinal != []; | ||
# Note: We use `or true` in case `lib.types` from an older nixpkgs version | ||
# that doesn't set `conditional` is used. Avoids some trouble down the road | ||
isDefined = type.conditional or true -> defsFinal != []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's maybe factor out the two type.conditional or true
s
@@ -162,6 +165,10 @@ rec { | |||
# nixos/doc/manual/development/option-types.xml! | |||
types = rec { | |||
|
|||
unconditional = elemType: elemType // { | |||
conditional = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conditional = false; | |
conditional = false; | |
description = "unconditional ${optionDescriptionPhrase (class: class == "noun" || class == "composite") elemType}"; | |
descriptionClass = "composite"; |
Maybe? Or lazy
? IDK
That proposed change only allows access to attributes on the right hand side of (EDIT) haven't tested |
Motivation for this change
Introduce
types.unconditional <elemType>
as a type, which when used as e.g.attrsOf (unconditional str)
can replacelazyAttrsOf str
. This type ensures that conditionalmkIf
definitions can't influence whether the option is defined or not, and therefore make the attribute set values be evaluated lazily. This notably also works withlistOf (unconditional str)
, making the list elements evaluated lazily, which was not possible before.Split off from #132448
Things done