Feature: Weighted default / Idiomatic way of changing the default #2159
Replies: 15 comments 3 replies
-
note that, depending on your use case and if/how users interact, you could also do things a bit the old fashioned way: like how you might do it excel or python or another language ... e.g. have a ValueUserInput, ValueUserDefault, ValueSystemDefault, and ValueFinal ... UserInput is what they've entered, SystemDefault is the provided default, UserDefault is the custom one, and Final is a formula which checks for those values (with |
Beta Was this translation helpful? Give feedback.
-
The problem is that what you are describing is a LOT of boilerplate that I would have to apply to literally every value. |
Beta Was this translation helpful? Give feedback.
-
So an example, from the tutorials is this:
this says, it can only be udp or tcp , and without further input, it will resolve to
it's ambiguous, and is essentially the same as if I didn't have a preferred mark at all so, what if I could mark *"udp" as weighted heavier than *"tcp" I suppose this would be most similar to a Technically CUE already supports this, since a And there are other similar functions, such as null/bottom coalescing. |
Beta Was this translation helpful? Give feedback.
-
Here's an idea:
This system could work similar to |
Beta Was this translation helpful? Give feedback.
-
turning the |
Beta Was this translation helpful? Give feedback.
-
Hello I am also very invested in this idea. here is my proposed solution adding the concept of weighted priority on defaults with
what do you gues think about this here is an example of it in practice |
Beta Was this translation helpful? Give feedback.
-
more generically speaking, a field has no default when the max(weight) contains multiple valid values. |
Beta Was this translation helpful? Give feedback.
-
@ghostsquad thanks for raising this, and welcome to CUE! Does the following approach satisfy your requirements? #A: {
defaults: {
k8s?: string
user?: string
more?: string
evenMore?: string
}
protocol?: string
protocol: *(*(*(*(defaults.evenMore | _|_) | defaults.more) | defaults.user) | defaults.k8s) | _
}
examples: [string]: #A
examples: eg0: defaults: {
}
examples: eg1: defaults: {
k8s: "test"
}
examples: eg2: defaults: {
k8s: "test"
user: "user"
}
examples: eg3: defaults: {
user: "user"
evenMore: "something"
}
examples: eg3: {
defaults: {
user: "user"
evenMore: "something"
}
protocol: "rubbish"
} Gives:
However, it would be good to get some more details on the problem you are trying to solve in your "opinion-based layer system", because that will really help to inform whether we can/should do more in CUE the language to help this sort of pattern. Can you flesh things out a bit more in pseudo code? Is @zzh8829's approach to layers close to what you want? If |
Beta Was this translation helpful? Give feedback.
-
@ghostsquad I've converted your feature request to a discussion whilst we flesh out what it is precisely that being proposed here. |
Beta Was this translation helpful? Give feedback.
-
@myitcv the example may solve the problem, but it's not intuitive because it's using ancillary fields. I really want a user to just say this:
and what that means, is that, if nothing is provided and there's no preference greater than 100, use the value |
Beta Was this translation helpful? Give feedback.
-
I believe CUE already supports these semantics: a concrete value is already the most specific thing you can be, thus it is used. Let's just widen this gap. |
Beta Was this translation helpful? Give feedback.
-
I actually don't think that multiple layers/defaults makes things unmanageable. I think being not being able to trace where a value is coming from is what makes configuration unmanageable. I'm creating some user stories for a tool I'm working on that should hopefully help explain why multiple defaults are needed (with different weights) |
Beta Was this translation helpful? Give feedback.
-
I found the previous community slide deck, and I don't feel like multi-field defaults is very idiomatic. Here are some use cases / user stories (also in the Github discussion)
The problem exists between layers 1 & 2 though. Where the base layer provides value by specifying defaults, but the base layer isn't the only base layer, it's just a jumping off point (similar to that of how k8s yaml manifests work today. e.g. if null then XYZ default is applied |
Beta Was this translation helpful? Give feedback.
-
I'm wondering if anyone else has had a chance to review this discussion? I'm still interested in this use case. |
Beta Was this translation helpful? Give feedback.
-
This reminds me of the NixOS module system where you cannot have conflicting values when merging the config but you can resolve the conflict with priorities. So that if you take an upstream config you can always "force" a value (given it's the right type) by using an higher priority. The new In the current situation with I think the approach to take with |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
I'm building an opinion-based layer system, and I'd like to use things like
"foo" | *"bar"
(think about how the "if null then X" is the behavior of many fields), but allowing someone else to come along and say, actually, I prefer thatfoo
be the default instead if the user doesn't specify something different.Describe the solution you'd like
Either an explanation of how to accomplish this, or syntax to allow for a weight-based preference to default values.
Describe alternatives you've considered
N/A - I'm still learning CUE, coming from Jsonnet experience. Trying to figure out how to accomplish this common use-case.
Additional context
N/A
Beta Was this translation helpful? Give feedback.
All reactions