Repository navigation
[Feature Request] Extend @optional decorator with groups #1096
Description
Description
Allow @optional decorators to include an argument to define a group so that a whole group is either defined or not.
Example
# Microsoft OAuth client. Set together with its secret and tenant.
# @optional(microsoft)
MICROSOFT_CLIENT_ID=
# Secret belonging to the Microsoft OAuth client above.
# @sensitive @optional(microsoft)
MICROSOFT_CLIENT_SECRET=This will throw if only one of the group variables is defined
Motivation
It is common to have multiple variables that are optional as a whole, but required if one is defined
Proposed Solution
No response
Alternatives
A new decorator defining the name and the included variables
# @optionalGroup(google, GOOGLE_DRIVE_CLIENT_ID, GOOGLE_DRIVE_CLIENT_SECRET)Additional Information
No response
Activity
pullfrog commentedon Sep 17, 2026
theoephraim commentedon Sep 18, 2026
I realize it's not exactly the same, but why not just base requiredness off of one key item in the group
Or add another internal var to track intent more clearly
wrong7 commentedon Sep 18, 2026
Yes that would work but only one way. If you define
MICROSOFT_SECRET_KEYbut notMICROSOFT_CLIENT_KEYnothing would tell you one is missing.The second aproach requires a new variable, sure it works but it's not very elegant.
What this request is about is just QoL honestly
theoephraim commentedon Sep 18, 2026
Yeah I see the point. Just not positive it's worth adding another way to do it. The explicit key is nice because you declare the intent first.
If we do add it, it would be something like
# @optional={group=somename}since theoptional()implies its a function and can be called multiple times on an item. I guess my hesitation here is that the intent is not immediately evident. Like this means they must all be set, or all be empty, and thats not necessarily obvious. Should I also be able to set it on@requiredand a group on either one means all or none?The alternative is to put in a root decorator, which is a bit clearer, but also removes it from the items, and then there is a question of how an explicit required/optional on a specific item would interact with it.
Will think on it a bit...
wrong7 commentedon Sep 18, 2026
A root decorator was my first approach but as you said it removes it from the item.
Maybe what's needed here is just some functionality for the
@tag()decorator beyond CLI filtering.I'm thinking you could declare a tag and then check with an internal variable the values of all of the variables with the tag (I don't think you can do this now).
But then again this wouldn't be a straightforward method to achieve this, and it would be much more trouble than defining the
@internal ENABLE_MICROSOFT=falseyou mentioned earlier.I think the conclusion here is that
@tag()is already a group and it has more potential to it than just CLI filtering.theoephraim commentedon Sep 19, 2026
Agreed that tags have a lot of potential to be used for many things! I’ll think on it a bit.
timche commentedon Sep 28, 2026
+1 for this. A data point on why the existing decorators can't express it: the symmetric version (each item required when any of the others is set) is rejected as a cycle, even when none of them is set. Tried on 1.21.0:
Routing it through one internal helper (
ANY_SET=not(isEmpty(concat(...)))with@required=$ANY_SETon each item) hits the same cycle. So today the choice is between anchoring on one key (only one direction is checked) and an explicit enable flag. The flag works, but for groups like credentials for an optional integration, it means a variable whose only job is to restate that the others are set. Something like@optional={group=azure}, or a tag-based check, would cover it without the extra variable.theoephraim commentedon Sep 28, 2026
@timche - thanks for the additional data point