Open maxwell-k opened 1 year ago
This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response.
There seems to have been prior discussion on this as well on this slack thread. And is actually related to how the yaml.v2
library we use to marshal our YAML treats floating points, a user had previously created an issue related to this here.
The key thoughts that would be worth capturing here as well would be:
.X
ytt
s output unable to differentiate between these two values in your case?I ran a few cases real quick through ytt, to see how the language behaves if we drop the .X
and ytt
seems to be able to realise when a float-like representation is required.
Input:
a: #@ 1.0
b: #@ 1.1
c: #@ 1.0 + 2
d: #@ 1.0 + 1.1
e: #@ 2.0 * 2.1
Output:
a: 1
b: 1.1
c: 3
d: 2.1
e: 4.2
I switched up the tags as we are gathering more information here.
What would be useful to understand is, if this is blocking you from using ytt
for your needs? This would help us prioritise this concern!
Furthermore, it is worth adding that we are thinking about moving from yaml.v2
=> yaml.v3
for our marshalling needs as we would like to support emitting comments (#63 ). And judging from this comment. It should also ensure that original formatting is retained while marshalling 🚀
Thank you for looking at this. I understand that you are relying on the underlying library. Moving yaml.v2
=> yaml.v3
sounds like an interesting solution.
What would be useful to understand is, if this is blocking you from using ytt for your needs? This would help us prioritise this concern!
This issue is currently blocking our use of ytt.
To explain a few more details of the use case: we're trying to use ytt overlays to change parameters before we run a vessel simulation. ytt is perfect for succinctly describing the edits (or you could call them patches or overlays) that we need to apply before each run.
The problem is that as well as applying the overlay as expected, ytt unexpectedly converts certain floats to integers. This unexpected change causes a part of our application to error.
Reading the links that you provided we could perhaps tag the input as a workaround. It seems that ytt
also converts certain floats that are explicitly tagged to be floats to integers:
Input
a: !!float 1.0
b: !!float 1
c: !!float 1.1
Output
a: 1
b: 1
c: 1.1
@maxwell-k Thanks for the details on your use case. As mentioned above, we are soon planning on moving to yaml.v3 in certain scenarios and that would allow preserving the intermediate representation in the original format.
Meanwhile, looks like the explicit tagging with !!float
would work on most cases except for floats like 1.0, 2.0, 3.0 where it gets converted to integer.
Here are few examples I ran through the ytt playground.
We would be happy to discuss any further questions if you have. Thanks for reaching out!
Thanks @vmunishwar ; it is d and h that block our use of ytt.
If h resulted in 1.0
we could workaround the unpredictable result from d. Ideally neither d nor h would result in an integer data type.
I guess we'll wait for the move to yaml.v3
; thank you.
Hello @vmunishwar, we are experiencing the same issue. What is the current status on this issue?
The move to YAML v3 is unfortunately still unprioritised as it might introduce breaking changes
What steps did you take:
ytt
appears to convert input floats to integers, for example, running the command below:I am passing
ytt
a single floating point number - 1.0 - encoded as YAML.What happened:
The output from
ytt
is an integer:What did you expect:
I expected the output to be a float:
Anything else you would like to add:
I understand that integer and floating point data types differ in the YAML spec. This is a simplified example from input to an application. That application behaves differently if its YAML input contains an integer or a float. In the actual use case these numbers are embedded inside more complex structures.
Environment:
Version:
OS Fedora Linux 26 on AMD 64.
/etc/os-release
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible" 👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.