5 ms·

Offtopic: I'm saddened to see YAML get a bad rap for effectively being shoehorned to fit a task that it's just bad at. In my experience, YAML is a great forma

Offtopic: I'm saddened to see YAML get a bad rap for effectively being shoehorned to fit a task that it's just bad at. In my experience, YAML is a great format for legibly declaring a dict/array structure, with added benefits over JSON like anchors/references (effectively pointers, which thus allow it to describe a graph), comments, and overloads (great for defaults!). But YAML has no facilities for conditionals, loops, or any logic. So these get tacked-on, ad-hoc, by systems that need them, and that pulls YAML towards Greenspun's Tenth Rule ("Any sufficiently complicated [system] contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp") I'm glad better languages like Dhall exist for the problem-space that YAML is just not designed for.

smitty1e 4y ago
My grief is seeing YAML/JSON browbeaten past being static textual files, and into being interpreted files with nasty embedded functions (looking at YOU, CloudFormation). My latest project is gaffing all that off and using .xlsx to hold configuration, openpyxl to load the .xlsx, and then transforming the content into a target format (terraform) in the python. Let each piece in the system do what it's good at.
- chii 4y ago
  > using .xlsx to hold configuration what the?! I would imagine that .xlsx is even worse than a plain text file for holding configuration. You have to open it with a spreadsheet editor, and how would you diff a binary format when committing into source repository?
  - smitty1e 4y ago
    Git does binaries. Excel is on the desktop, and ot has diffing tools. This is a work project, not something for regular GitHub release.
- Octabrain 4y ago
  > Let each piece in the system do what it's good at. Althought I strongly dislike the idea of introducing Excel in any equation, I wholehearthly agree with that quoted statement of yours. However, if I were you, I would use csv format. It can be easily read/edit from Excel if that's a strict requirement, and in that way, you can keep a grepable plain text versioned in the repository (the csv itself). The best of two worlds I guess. Also, from the top of my head, the Python standard library has a module for reading CSV, so less dependencies too.
wyuenho 4y ago
I'm saddened to see people complaining about YAML when it's actually Helm and Jinja and treating configs files as plain text file like it's still the early 2000s that are the problem. In my experience, syntax tree based composition tools like kustomize solves much of the problem for me. I appreciate this is sorta kinda new for devops people, but come on, this idea has been around for decades.
Gigachad 4y ago
If you need all of those features I think the best way is to just define objects in TypeScript. You have the full power of a real and well understood language then.
rpeszek 4y ago
About YAML, I like YAML too, only not so much for 5K+ configuration lines.

smitty1e 4y ago

My grief is seeing YAML/JSON browbeaten past being static textual files, and into being interpreted files with nasty embedded functions (looking at YOU, CloudFormation). My latest project is gaffing all that off and using .xlsx to hold configuration, openpyxl to load the .xlsx, and then transforming the content into a target format (terraform) in the python. Let each piece in the system do what it's good at.

chii 4y ago
> using .xlsx to hold configuration what the?! I would imagine that .xlsx is even worse than a plain text file for holding configuration. You have to open it with a spreadsheet editor, and how would you diff a binary format when committing into source repository?
- smitty1e 4y ago
  Git does binaries. Excel is on the desktop, and ot has diffing tools. This is a work project, not something for regular GitHub release.
Octabrain 4y ago
> Let each piece in the system do what it's good at. Althought I strongly dislike the idea of introducing Excel in any equation, I wholehearthly agree with that quoted statement of yours. However, if I were you, I would use csv format. It can be easily read/edit from Excel if that's a strict requirement, and in that way, you can keep a grepable plain text versioned in the repository (the csv itself). The best of two worlds I guess. Also, from the top of my head, the Python standard library has a module for reading CSV, so less dependencies too.

wyuenho 4y ago

I'm saddened to see people complaining about YAML when it's actually Helm and Jinja and treating configs files as plain text file like it's still the early 2000s that are the problem. In my experience, syntax tree based composition tools like kustomize solves much of the problem for me. I appreciate this is sorta kinda new for devops people, but come on, this idea has been around for decades.

Gigachad 4y ago

If you need all of those features I think the best way is to just define objects in TypeScript. You have the full power of a real and well understood language then.

rpeszek 4y ago

About YAML, I like YAML too, only not so much for 5K+ configuration lines.