4 ms·
I don't understand this. YAML has limitations. All formats have limitations. If a format is too limiting, don't use it. Pick one more suitable, or come up with
by rendall 5y ago
I don't understand this. YAML has limitations. All formats have limitations. If a format is too limiting, don't use it. Pick one more suitable, or come up with another one, like NestedText (or whatever). What is this need to tell everyone else to "move on" from using some format because it doesn't sit your specific preferences or use case?
- remram 5y agoI don't understand this. Opinions are not universal, every blogger has limitations. If you don't agree with a HN title, don't read it. Pick the next one or read another site. What is this need to tell everyone that you don't like them to tell everyone to "move on" just because it doesn't sit your specific preferences in formulation?
- rendall 5y agoI see what you did there, but it comes off as mocking and not so clever. The difference between my post and that blog, and your reply for that matter, is that I'm not telling anyone not to read it. I'm inviting you to comment on why people feel the need to tell others to move on. Here's a good example of how to respectfully disagree: https://news.ycombinator.com/item?id=29220994 https://news.ycombinator.com/item?id=29220994
- firearm-halter 5y agoThe person that creates the config file does not necessarily choose the config file format. In the example, github chose YAML and everyone using github actions must use it. YAML is error prone, as everyone that tests with Python is finding out as the add Python 3.10 to their regression tests. This is a plea to organizations like github to stop choosing YAML.
- rendall 5y agoAs not a Python programmer, I'm struggling to understand the issue. Your (or blogger's) claim is that GitHub misparses the YAML actions config when it comes specifically to Python? Or that YAML is inherently inadequate to the task of representing Python's necessary actions?
- kzrdude 5y agoThe Python 3.10 issue is this, in yaml: Python_versions: - 3.8 - 3.9 Then we add the new version in our yaml file: Python_versions: - 3.8 - 3.9 - 3.10 But now we discover that 3.10 is parsed as a float, just like the other ones were. But the problem is that 3.10 becomes 3.1, the equivalent float value! With 3.9 we didn't notice this problem. I'm not sure what the name for this problem is. It's something like.. an unfaithful but unintentionally working representation. Until it doesn't work anymore. The solution in YAML is to quote the values so that they become strings as intended.
- deadbunny 5y ago> I'm not sure what the name for this problem is. Not reading the manual? Same thing would happen in JSON. Sure it's annoying but all the YAML docs I've ever read state that unquoted numbers are ints/floats.
- jeroenhd 5y agoHow is that different from other formats? Take JSON: {"python_versions": [3.8, 3.9, 3.10]} This is a problem in any config language that doesn't enforce types, and jf it does enforce types, you should've used quotes already (like you really should've been before 3.10 was added to the list). Similar problems also exist in many config formats with scientific notation (2e345) or hexadecimal notation (0x12345) or octal notation (012345, no that's not a decimal number in many programming languages and config formats!). What commonly supported alternative would you suggest for this use case?
- kzrdude 5y agoThe difference from JSON is that in JSON, you always have to write "" to get strings. In YAML you can just write blah and and it becomes a string. Except when it doesn't, when it matches some other type of value.
- sigzero 5y agoSure, if you ignore what the YAML documentation actually says.
- ccouzens 5y agoYAML is a superset of JSON. Which means anything that accepts YAML accepts JSON. So you can write your Github action code in JSON (with a yml file extension).
- bmn__ 5y ago> YAML is a superset of JSON. That's false. http://p3rl.org/JSON::XS#JSON-and-YAML http://p3rl.org/JSON::XS#JSON-and-YAML
- ccouzens 5y agoInteresting. Thanks for bringing that to my attention. It sounds like the differences are unlikely to be encountered in conventional config files, especially those written by hand. From that link I understand the source of problems to be: Object keys longer than 1024 "stream characters". But these wouldn't be valid in any other yaml syntax either. Some Unicode characters in strings (characters outside of BMP). An escape sequence that is technically valid in JSON but never required.
- initplus 5y agoYAML's lack of limitations is the source of much of the difficulty with the format. The numerous ways to represent basic data (arrays, strings etc) is a common source of error. YAML doesn't have enough limitations! And you can't pick what config format a tool you need uses.
- rendall 5y agoBut, GitHub, specifically has very specific guidelines on what to write and how to format it, and will give pretty detailed error messages if it's badly formatted. Not to mention tooling to format and highlight. I'm not seeing how the proposed NestedText is inherently free from those same issues: the need for tooling, guidance, error messages. Is the claim that it's easier?
- firearm-halter 5y agoI think the important difference between NestedText and YAML is that NestedText does not try to convert the text to numbers or booleans. YAML converts on to True and 3.10 to 3.1, which in this case is undesired. NestedText keeps text as strings. The idea is that end application should be the one that determines if on is a string or a boolean and whether 3.10 is a string or a number. Its all in the name. All leaf values are strings. It is literally nested text.
- tannhaeuser 5y agoEspecially since the post title doesn't match the linked article's heading.
- rendall 5y agoYes! Thanks for pointing that out! You're right!