4 ms·

Although I mostly loathe DSLs and have been wanting something almost precisely like this for quite some time looking at the examples I think I might prefer the

Although I mostly loathe DSLs and have been wanting something almost precisely like this for quite some time looking at the examples I think I might prefer the Ansible YAML approach better. Ansible YAML is definitely more tidy and concise despite Python's awesome readability. And even though you get all the benefits of the full Python language is a definite advantage (try turning a list ["www1", "www2", "www3"] into the string "www1:443,www2:443,www3:443" without plugins or some serious ugliness) I wonder if having Ansible/Jinja2 preclude most of those abilities is a feature and not a disadvantage. Either way as someone who has just found himself in an environment that uses Chef/Ruby for Ops stuff and Python for everything else I'll be watching this closely.

rkangel 8y ago
Based on Ansible and other systems going all the way back to GNU make, I believe that the programming language version wins every time. We're programmers, and sometimes we're going to need to program to solve this problem. Taking away that option is always a pain. Even if what you wanted was possible with Jinja2, it wasn't necessarily very readable anyway. Proponents of it will point at that this is the sort of thing that Lisp is good (and they'd be right), but there are other functional languages that are good at it too - the simpler syntax is a bit of a headstart. Elixir's macros system enables a number of lovely little DSLs (e.g. Phoenix router or Ecto DB schemas).
rmetzler 8y ago
I agree that your problem is much harder than it should be and I think it is due to the format() filter not being fit for use in map(). Nevertheless here are 3 versions how you could solve this problem in Jinja2: {{ list | map('regex_replace', '(.*)', '\\1:443') | join(',') }} {{ list | zip_longest([], fillvalue='443') | map('join', ':') | join(',') }} {% for item in list %}{{item}}:443{%- if not loop.last %},{%- endif %}{%- endfor %} I wish the following would be possible: {{ list | map('format', '%s:443') | join(',') }}
- VectorLock 8y ago
  I ended up using a custom plugin to make it easier. The actual real world attempt was more complicated and had a crappier version of Ansible. I also wish the map/format one worked.
- mpdehaan2 8y ago
  My historical argument was always that if a playbook looks ugly, it is wrong. Over the years I haven't been around to keep saying that, but I'd be inclined to have to find ways to open up the programming model while still keeping the mostly organized guide-rails in place.

rkangel 8y ago

Based on Ansible and other systems going all the way back to GNU make, I believe that the programming language version wins every time. We're programmers, and sometimes we're going to need to program to solve this problem. Taking away that option is always a pain. Even if what you wanted was possible with Jinja2, it wasn't necessarily very readable anyway. Proponents of it will point at that this is the sort of thing that Lisp is good (and they'd be right), but there are other functional languages that are good at it too - the simpler syntax is a bit of a headstart. Elixir's macros system enables a number of lovely little DSLs (e.g. Phoenix router or Ecto DB schemas).

rmetzler 8y ago

I agree that your problem is much harder than it should be and I think it is due to the format() filter not being fit for use in map(). Nevertheless here are 3 versions how you could solve this problem in Jinja2: {{ list | map('regex_replace', '(.*)', '\\1:443') | join(',') }} {{ list | zip_longest([], fillvalue='443') | map('join', ':') | join(',') }} {% for item in list %}{{item}}:443{%- if not loop.last %},{%- endif %}{%- endfor %} I wish the following would be possible: {{ list | map('format', '%s:443') | join(',') }}

VectorLock 8y ago
I ended up using a custom plugin to make it easier. The actual real world attempt was more complicated and had a crappier version of Ansible. I also wish the map/format one worked.
mpdehaan2 8y ago
My historical argument was always that if a playbook looks ugly, it is wrong. Over the years I haven't been around to keep saying that, but I'd be inclined to have to find ways to open up the programming model while still keeping the mostly organized guide-rails in place.