-
Notifications
You must be signed in to change notification settings - Fork 586
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
Update go-cty and improve documentation for optional and default attributes #564
Conversation
liamcervante
commented
Oct 31, 2022
•
edited
Loading
edited
- Update the typeexpr README with some discussion of optional and default object attributes
- Remove references in the godoc that state you should apply defaults before conversion
- instead, recommend that you should actually convert first
- the latest versions of convert will introduce null values for optional attributes, and the default functions in hcl will overwrite null values (note, there are actually tests for this already)
- Update go-cty to the latest version
- go-cty is now much more flexible around unsafe conversions so some tests started failing because they expected go-cty to not be able to do conversions that it can now do
- added new tests that test more complex behaviour, and verify the old tests are now expected to succeed.
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.
Docs changes look good to me, thanks! I don't really understand the test updates, which makes me a bit nervous. I left a question inline.
"listOf1Tuple": cty.ListVal([]cty.Value{cty.TupleVal([]cty.Value{cty.True})}), | ||
"listOf0Tuple": cty.ListVal([]cty.Value{cty.EmptyTupleVal}), |
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.
I am surprised that you were able to make this test fail by changing it in this way. An attempt to recreate this in a terraform console
session:
> true ? tolist([[1]]) : tolist([[2,3]])
tolist([
tolist([
1,
]),
])
> false ? tolist([[1]]) : tolist([[2,3]])
tolist([
tolist([
2,
3,
]),
])
>
Neither of these error. Am I missing something?
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.
I think the key here is that the two elements of the "2-tuple" must be of types that have no common base type, or else HCL will notice that it can convert the two tuples into lists of numbers to find a common type.
> true ? tolist([[1]]) : tolist([[2, true]])
╷
│ Error: Inconsistent conditional result types
│
│ on <console-input> line 1:
│ (source code not available)
│
│ The true and false result expressions must have consistent types.
│ Mismatched list element types: The 'true' tuple has length 1, but
│ the 'false' tuple has length 2.
╵
> type(true ? tolist([[1]]) : tolist([[2,3]]))
list(list(number))
This is unfortunately a case where the "mismatch message" heuristic makes a poor choice about what to comment on: it is true that the tuple types are of different lengths, but it would be perhaps more relevant to say that the second inner tuple can't reduce to a list because its types are mismatching. I don't really know how to define a suitable heuristic to detect that situation or how to describe the detected problem concisely in English, though. 😖
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.
Oh, that makes sense!
It might be worth leaving a comment to that effect in this test, then. Or renaming the variables to tupleBoolNumber
and tupleBool
.
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.
Yes, what Martin said!
I've added a comment explaining why the test cases fail.
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.
✅ with an inline suggestion to make the semantics of the updated test a bit clearer.
"listOf1Tuple": cty.ListVal([]cty.Value{cty.TupleVal([]cty.Value{cty.True})}), | ||
"listOf0Tuple": cty.ListVal([]cty.Value{cty.EmptyTupleVal}), |
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.
Oh, that makes sense!
It might be worth leaving a comment to that effect in this test, then. Or renaming the variables to tupleBoolNumber
and tupleBool
.