You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we are dealing with buildInputs which is a list containing potential more than 1 element, using the plural form lib.optionals seems more natural.
Using lib.optionals allows you to add more than one element after the condition. If you try to do the same with lib.optional, you might end up with lists within lists.
I've been submitting a couple of PRs against nixpkgs before and some maintainers asked me to use lib.optionals instead of lib.optional.
The text was updated successfully, but these errors were encountered:
Hello,
How about having a rule explaining why
lib.optionals
is a better idea thanlib.optional
?Here are some rough ideas:
lib.optional
does more than expected. It wraps its contents into a list. This adds an extra cognitive load for newcomers.buildInputs
which is a list containing potential more than 1 element, using the plural formlib.optionals
seems more natural.lib.optionals
allows you to add more than one element after the condition. If you try to do the same withlib.optional
, you might end up with lists within lists.nixpkgs
before and some maintainers asked me to uselib.optionals
instead oflib.optional
.The text was updated successfully, but these errors were encountered: