Skip to content
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

Treat literals as strings, do not convert them to Python datatypes #16

Open
AlexandreDecan opened this issue Apr 4, 2024 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@AlexandreDecan
Copy link
Collaborator

When reading a workflow file, ruamel.yaml is used to parse the yaml and its default behaviour is applied. The default behaviour means that all literals that have a specific meaning in yaml (such as "true", "false", integers, floats, etc.) are converted to their corresponding Python data types.

The problem is that when we report the changes that we find between two workflow files, we report them as Python objects, implying for example that key: true changed to key: false will be reported as True becoming False (where True and False are Booleans) instead of true becoming false (as strings).

A possibility would be to convert all these specific values to strings when reading them through ruamel. However, (1) it doesn't seem easy to tune ruamel to get this behaviour (it seems we'll have to change the behaviour of a subclass of the Constructor class, but support for specific data types seems to be implemented through class methods that are called explicitly); (2) this also means that our similarity function will be applied exclusively on strings, implying that the difference between (for example) True and False won't be 1 anymore, but the result of difflib.SequenceMatcher's ratio on the two strings. Similarly, comparing 11 and 12 will lead to a similarity of 50% where it is currently 0%.

To be discussed...

@AlexandreDecan AlexandreDecan added enhancement New feature or request question Further information is requested labels Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant