5 ms·

Solution: quote values. Like in JSON.

IshKebab 2y ago
It's not really a solution though because you only notice you need to do it after it triggers a bug. You need a format that doesn't let you make this mistake in the first place, like [everything except YAML].
- Too 2y ago
  If the yaml is generated by code it should be quoted automatically, given that you have a sane yaml library. try this: yaml.dump({"gameServerVersion": "556474378"}, sys.stdout) It will correctly print the quoted version gameServerVersion: '556474378' At least with Python, strings are strings and there is a minimal risk you store a git hash coming from the output of a git subprocess command as a number. The only way this bug could have happened is if doing manual string templating. If you were doing that, equally or worse kind of bugs are waiting for you in any serialization format.
  - IshKebab 2y ago
    > The only way this bug could have happened is if doing manual string templating. I agree you should not do that, but it is common in the YAML world - if you're using YAML you've already decided you don't care if things are reliable. Given that they were using string templating, this would have been caught earlier using a different format. Of course there are other string templating mistakes that other formats would not catch (e.g. forgetting to escape strings), but they are still better than YAML.
    - kdjdjsj 2y ago
      The problem obviously is using string templating without proper escaping Any format would fail if used like that, be it YAML, JSON, XML...
      - immibis 2y ago
        This problem is specific to YAML because it doesn't require quoting.
- dijksterhuis 2y ago
  > It's not really a solution though because you only notice you need to do it after it triggers a bug. … the first couple of times. After causing the same bug multiple times its the user at fault, not the tool. YAML does a decent enough job. I think these are the relevant YAML spec sections from a quick glance. If someone wants to correct me, feel free. YAML spec on double quotes > The double-quoted style is specified by surrounding “"” indicators. This is the only style capable of expressing arbitrary strings, by using “\” escape sequences. This comes at the cost of having to escape the “\” and “"” characters. YAML spec on plain style > The plain (unquoted) style has no identifying indicators and provides no form of escaping. It is therefore the most readable, most limited and most context sensitive style. In addition to a restricted character set, a plain scalar must not be empty or contain leading or trailing white space characters.
  - wruza 2y ago
    the first couple of times Times every yaml user in the multiverse.
    - dijksterhuis 2y ago
      It’s a right of passage. Just like convincing your boss to switch the backend over to K8s and then realising a year later it was a mistake. Everyone does it.
  - IshKebab 2y ago
    > After causing the same bug multiple times its the user at fault, not the tool. Absolutely not. If the tool is so bad that users commonly make a mistake then the tool should prevent that mistake. This is a basic UX tenet that unfortunately many people do not know.
    - dijksterhuis 2y ago
      It’s a trade off in how the parsing works. No tool is perfect. :shrugs: The accepted safe default is to use double quotes. If folks don’t know that then that’s on them, not the tool. It’s in the spec. Good workmen don’t blame their tools. Edit — I know the UX tenet. I’ve worked in places where they thought using YAML for end users was a good idea. It’s not. It never will be. It’s a backend tool for engineers. So I agree with you in that specific UX case. But this isn’t an end-user UX case. It’s backend platform configuration. Use the right tool for the job, and use it the way it’s been designed —> Double quote strings in YAML.

It's not really a solution though because you only notice you need to do it after it triggers a bug. You need a format that doesn't let you make this mistake in the first place, like [everything except YAML].

Too 2y ago
If the yaml is generated by code it should be quoted automatically, given that you have a sane yaml library. try this: yaml.dump({"gameServerVersion": "556474378"}, sys.stdout) It will correctly print the quoted version gameServerVersion: '556474378' At least with Python, strings are strings and there is a minimal risk you store a git hash coming from the output of a git subprocess command as a number. The only way this bug could have happened is if doing manual string templating. If you were doing that, equally or worse kind of bugs are waiting for you in any serialization format.
- IshKebab 2y ago
  > The only way this bug could have happened is if doing manual string templating. I agree you should not do that, but it is common in the YAML world - if you're using YAML you've already decided you don't care if things are reliable. Given that they were using string templating, this would have been caught earlier using a different format. Of course there are other string templating mistakes that other formats would not catch (e.g. forgetting to escape strings), but they are still better than YAML.
  - kdjdjsj 2y ago
    The problem obviously is using string templating without proper escaping Any format would fail if used like that, be it YAML, JSON, XML...
    - immibis 2y ago
      This problem is specific to YAML because it doesn't require quoting.
dijksterhuis 2y ago
> It's not really a solution though because you only notice you need to do it after it triggers a bug. … the first couple of times. After causing the same bug multiple times its the user at fault, not the tool. YAML does a decent enough job. I think these are the relevant YAML spec sections from a quick glance. If someone wants to correct me, feel free. YAML spec on double quotes > The double-quoted style is specified by surrounding “"” indicators. This is the only style capable of expressing arbitrary strings, by using “\” escape sequences. This comes at the cost of having to escape the “\” and “"” characters. YAML spec on plain style > The plain (unquoted) style has no identifying indicators and provides no form of escaping. It is therefore the most readable, most limited and most context sensitive style. In addition to a restricted character set, a plain scalar must not be empty or contain leading or trailing white space characters.
- wruza 2y ago
  the first couple of times Times every yaml user in the multiverse.
  - dijksterhuis 2y ago
    It’s a right of passage. Just like convincing your boss to switch the backend over to K8s and then realising a year later it was a mistake. Everyone does it.
- IshKebab 2y ago
  > After causing the same bug multiple times its the user at fault, not the tool. Absolutely not. If the tool is so bad that users commonly make a mistake then the tool should prevent that mistake. This is a basic UX tenet that unfortunately many people do not know.
  - dijksterhuis 2y ago
    It’s a trade off in how the parsing works. No tool is perfect. :shrugs: The accepted safe default is to use double quotes. If folks don’t know that then that’s on them, not the tool. It’s in the spec. Good workmen don’t blame their tools. Edit — I know the UX tenet. I’ve worked in places where they thought using YAML for end users was a good idea. It’s not. It never will be. It’s a backend tool for engineers. So I agree with you in that specific UX case. But this isn’t an end-user UX case. It’s backend platform configuration. Use the right tool for the job, and use it the way it’s been designed —> Double quote strings in YAML.