3 ms·

This is why I started to craft my own format: BCL, https://github.com/wkhere/bcl https://github.com/wkhere/bcl Will not immediately help in all cases of YAML u

by kunley 3y ago

This is why I started to craft my own format: BCL, https://github.com/wkhere/bcl https://github.com/wkhere/bcl Will not immediately help in all cases of YAML usages, but at least can be a cooler way of defining resources in a Terraform-like style. In fact, it's already helpful as a replacement for HCL in one internal project, that was a final motivation to hack it. In a bigger picture, I have no idea how to help with YAML omnipresence in Kubernetes. More than a half of my problems at a $daily_job is how crude is consolidating a final Helm chart from different sources. I am not saying that Helm would be inherently a bad tool or my company has chosen pretty bad way of using it - I guess everyone is doing their best considering the ciscumstances. But manipulating textual templates with semantic whitespaces is just too error prone, and the detection of errors happens too late. I dare to say - Kubernetes would do much better with custom format based on a C-like syntax, instead if trying to prove how cool YAML is, especially when it isn't.

craftkiller 3y ago
Have you seen ucl? https://github.com/vstakhov/libucl https://github.com/vstakhov/libucl It seems very similar.
- kunley 3y ago
  Thanks for the link! Yeah, ucl looks syntactically similar. On the other hand, I am not sure if it has expressions, and the variables usage is limited - they need to be registered in the parser, so they are existing outside of the config file; plus, they seem to represent just text. My assumption was to use variables in the same file, to make the content more modular/DRY, and to evaluate expressions using these variables. Moreover, variables and expressions have basic types: int, float, string and bool. This is not an artificial need, I will give you concrete examples what I want to have in the config file: - port numbers increased from a base value (int arithmetic) - recalculated frequency/throughput values (float arithmetic) - fields enabled if some other condition is true (comparisons, bool arithmetic) - names concatenated from text and numbers What else... in BCL variables are internal to the file; I want also to resolve the information existing external to the file, which would be: env varables (planned builtin function getenv) and ideally, output of executing command (like shell's $(), also planned). With this I can express easily and shortly quite complex configurations. Actually thanks a lot for your comment, because answering this makes me realize I should put such information in the README of my project, maybe in some more structured way.
zamalek 3y ago
> I have no idea how to help with YAML omnipresence in Kubernetes. More than a half of my problems at a $daily_job There are two good features in YAML: multiline strings, and YAML is a JSON superset. You can use anything that generates JSON to generate YAML. Nickel can be evaluated to JSON: https://nickel-lang.org/ https://nickel-lang.org/
- marcosdumay 3y ago
  > YAML is a JSON superset On the sense that any JSON file is a valid YAML file. But absolutely not in the sense that you can just treat your json file as YAML and expect it to contain the correct data.
  - skitter 3y ago
    Hm, what JSON documents have a different meaning in YAML? I'd have hoped that with all names & strings being quoted and leading zeros being disallowed, that wouldn't be the case.
    - zamalek 3y ago
      I have never come across a case where JSON can't take the place of YAML, but I guess there could be edge cases.
    - marcosdumay 3y ago
      You can easily corrupt the meaning of your JSON by adding whitespace in YAML.
    - maple3142 3y ago
      Maybe duplicate keys in JSON counts? Some JSON parsers choose the first and some choose the last, and YAML directly forbid that.
  - kunley 3y ago
    Exactly my thought. Is it that an academic property, or are people serious about throwing JSON into running software that parses YAML and expect good results? (Should I add: on production, because I want my tools to be used on production, but that's just me)
mongol 3y ago
This talk from Nixcon was inspiring https://youtu.be/SEA1Qm8K4gY?feature=shared https://youtu.be/SEA1Qm8K4gY?feature=shared

by kunley 3y ago

craftkiller 3y ago

Have you seen ucl? https://github.com/vstakhov/libucl https://github.com/vstakhov/libucl It seems very similar.

kunley 3y ago
Thanks for the link! Yeah, ucl looks syntactically similar. On the other hand, I am not sure if it has expressions, and the variables usage is limited - they need to be registered in the parser, so they are existing outside of the config file; plus, they seem to represent just text. My assumption was to use variables in the same file, to make the content more modular/DRY, and to evaluate expressions using these variables. Moreover, variables and expressions have basic types: int, float, string and bool. This is not an artificial need, I will give you concrete examples what I want to have in the config file: - port numbers increased from a base value (int arithmetic) - recalculated frequency/throughput values (float arithmetic) - fields enabled if some other condition is true (comparisons, bool arithmetic) - names concatenated from text and numbers What else... in BCL variables are internal to the file; I want also to resolve the information existing external to the file, which would be: env varables (planned builtin function getenv) and ideally, output of executing command (like shell's $(), also planned). With this I can express easily and shortly quite complex configurations. Actually thanks a lot for your comment, because answering this makes me realize I should put such information in the README of my project, maybe in some more structured way.

zamalek 3y ago

> I have no idea how to help with YAML omnipresence in Kubernetes. More than a half of my problems at a $daily_job There are two good features in YAML: multiline strings, and YAML is a JSON superset. You can use anything that generates JSON to generate YAML. Nickel can be evaluated to JSON: https://nickel-lang.org/ https://nickel-lang.org/

marcosdumay 3y ago
> YAML is a JSON superset On the sense that any JSON file is a valid YAML file. But absolutely not in the sense that you can just treat your json file as YAML and expect it to contain the correct data.
- skitter 3y ago
  Hm, what JSON documents have a different meaning in YAML? I'd have hoped that with all names & strings being quoted and leading zeros being disallowed, that wouldn't be the case.
  - zamalek 3y ago
    I have never come across a case where JSON can't take the place of YAML, but I guess there could be edge cases.
  - marcosdumay 3y ago
    You can easily corrupt the meaning of your JSON by adding whitespace in YAML.
  - maple3142 3y ago
    Maybe duplicate keys in JSON counts? Some JSON parsers choose the first and some choose the last, and YAML directly forbid that.
- kunley 3y ago
  Exactly my thought. Is it that an academic property, or are people serious about throwing JSON into running software that parses YAML and expect good results? (Should I add: on production, because I want my tools to be used on production, but that's just me)

mongol 3y ago

This talk from Nixcon was inspiring https://youtu.be/SEA1Qm8K4gY?feature=shared https://youtu.be/SEA1Qm8K4gY?feature=shared