I decided to compare this behavior with pure python (as it is also dynamically typed and closely resembles starlark), and although you can define something similar:
Are the authors open to adding determinism here? This can result in hard to reason about configurations due to inadvertent user error. One naive solution would be to sort fields by name to ensure some type of deterministic ordering.
Here's a reproduction of the issue I'm hitting:
Note,
Value
contains a oneof - https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/struct.proto#L62 Repeatedly invocating the code now returns non-deterministic results:Looks like the non-determinism is in part due to that fact that the fields of the returned proto object are stored internally in a go
map[string]starlark.Value
which has non-deterministic ordering, and the oneof field that is processed last wins - https://github.com/stripe/skycfg/blob/trunk/go/protomodule/protomodule_message.go#L279Looks like the intent was to mimic the behavior in
dynamicpb
- https://github.com/stripe/skycfg/pull/90/files#r692217496I decided to compare this behavior with pure python (as it is also dynamically typed and closely resembles starlark), and although you can define something similar:
The output is deterministic (I suspect because python 3.7 introduced dictionaries that maintained insertion order https://stackoverflow.com/questions/39980323/are-dictionaries-ordered-in-python-3-6)
Are the authors open to adding determinism here? This can result in hard to reason about configurations due to inadvertent user error. One naive solution would be to sort fields by name to ensure some type of deterministic ordering.