In the documentation, and for terseness, many task examples are given like:- apt: pkg=package_name state=installed update_cache=yesHowever, for version control, legibility, etc., it's usually preferred (at least as far as I've seen) to use a parameter-per-line approach, and there are two basic ways to do this with normal YAML syntax, first, with the YAML escape character and the parameters formatted the same (key=value):
- apt: >pkg=package_namestate=installedupdate_cache=yes
And second, using a normal YAML collection:- apt:pkg: package_namestate: installedupdate_cache: yes
To my eye, both are valid approaches—with the edge towards normal YAML collections, since syntax highlighting will allow for the keys to be highlighted as such, and values will be in the normal string/bool/constant mode. So visually, I lean towards the second option.
Going further, though, how would you handle tasks that use `command` or `shell` (or something similar), where the main portion of the task is not a key-value set, but just a given parameter?- command: >/usr/bin/executable --option 1creates=/some/path/herechdir=/home/johndoe
I know there's the option of adding an 'args' parameter and splitting out creates/chdir/other options into another separate collection, but that seems like an anti-pattern to me. Additionally, you would still have the command itself, which I like having on it's own line for clarity's sake:- command: >/usr/bin/executable --option 1args:creates: /some/path/here
chdir: /home/johndoe
How do you deal with key-value pairs in your tasks? What is the preferred and/or most used method? From what I've seen, it's usually a bit of a hodgepodge, and there are still many playbooks, roles, and examples out there with one-line tasks which are impossible to read/maintain unless extremely simple.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/52876e78-8c0c-455b-8c81-6a3ebc5a50ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On Mon, Aug 25, 2014 at 9:49 AM, Jeff Geerling <geerl...@gmail.com> wrote:
In the documentation, and for terseness, many task examples are given like:- apt: pkg=package_name state=installed update_cache=yesHowever, for version control, legibility, etc., it's usually preferred (at least as far as I've seen) to use a parameter-per-line approach, and there are two basic ways to do this with normal YAML syntax, first, with the YAML escape character and the parameters formatted the same (key=value):This has not been the case.
- apt: >pkg=package_namestate=installedupdate_cache=yesI don't care for this form, as if you have to pass structured data, you need to go to what you have next:And second, using a normal YAML collection:- apt:pkg: package_namestate: installedupdate_cache: yesThis is ideal for longer line things.
To my eye, both are valid approaches—with the edge towards normal YAML collections, since syntax highlighting will allow for the keys to be highlighted as such, and values will be in the normal string/bool/constant mode. So visually, I lean towards the second option.Syntax highlighting is not just a question of YAML, but also the variables, if you want that.This is why someone, for instance, wrote a Sublime Text plugin.
Going further, though, how would you handle tasks that use `command` or `shell` (or something similar), where the main portion of the task is not a key-value set, but just a given parameter?- command: >/usr/bin/executable --option 1creates=/some/path/herechdir=/home/johndoeKeeping them on one line is generally common.
I know there's the option of adding an 'args' parameter and splitting out creates/chdir/other options into another separate collection, but that seems like an anti-pattern to me. Additionally, you would still have the command itself, which I like having on it's own line for clarity's sake:- command: >/usr/bin/executable --option 1args:creates: /some/path/herechdir: /home/johndoeThis is an imaginary non-syntax, because you're mixing a string argument with a hash, but I think that's what you meant.
Args is only there for a legacy support, and no longer used.
How do you deal with key-value pairs in your tasks? What is the preferred and/or most used method? From what I've seen, it's usually a bit of a hodgepodge, and there are still many playbooks, roles, and examples out there with one-line tasks which are impossible to read/maintain unless extremely simple.All are valid, though the form you have with ">" is less desirable than passing a dictionary when you are already breaking things up into multiple lines.
On Monday, August 25, 2014 9:02:13 AM UTC-5, Michael DeHaan wrote:On Mon, Aug 25, 2014 at 9:49 AM, Jeff Geerling <geerl...@gmail.com> wrote:
In the documentation, and for terseness, many task examples are given like:- apt: pkg=package_name state=installed update_cache=yesHowever, for version control, legibility, etc., it's usually preferred (at least as far as I've seen) to use a parameter-per-line approach, and there are two basic ways to do this with normal YAML syntax, first, with the YAML escape character and the parameters formatted the same (key=value):This has not been the case.To each his own :) - but I've seen multiline more often than not, especially when tasks have 3+ parameters. Usually there's a mix, but it's hard to digest a task with 6+ parameters on one line.
Ah, didn't know that—it's currently displayed as one of the examples on the command module docs page (http://docs.ansible.com/command_module.html) — should I open a PR to remove that example?
How do you deal with key-value pairs in your tasks? What is the preferred and/or most used method? From what I've seen, it's usually a bit of a hodgepodge, and there are still many playbooks, roles, and examples out there with one-line tasks which are impossible to read/maintain unless extremely simple.All are valid, though the form you have with ">" is less desirable than passing a dictionary when you are already breaking things up into multiple lines.True!Thanks for the input,Jeff Geerling
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/37a5f704-409d-4e0a-98b8-9c0ad290a264%40googlegroups.com.
In the documentation, and for terseness, many task examples are given like:- apt: pkg=package_name state=installed update_cache=yesHowever, for version control, legibility, etc., it's usually preferred (at least as far as I've seen) to use a parameter-per-line approach, and there are two basic ways to do this with normal YAML syntax, first, with the YAML escape character and the parameters formatted the same (key=value):- apt: >pkg=package_namestate=installedupdate_cache=yesAnd second, using a normal YAML collection:- apt:pkg: package_namestate: installedupdate_cache: yesTo my eye, both are valid approaches—with the edge towards normal YAML collections, since syntax highlighting will allow for the keys to be highlighted as such, and values will be in the normal string/bool/constant mode. So visually, I lean towards the second option.
My feeling is, in this day of widescreen monitors and laptops, there's plenty of room in nearly all cases, and 79 character line wrap is obsolete.
Making more concise playbooks makes them easier to read and skim, rather than things being several pages long.I do believe in significant use of whitespace between lines, giving every task a "name:" attribute, and things like that.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/a7382aeb-9099-48f8-885d-9c32bce5490b%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/21499.39151.226836.102627%40gargle.gargle.HOWL.
Yep, style is a team thing.Part of this discussion was because Jeff is writing a book, I would prefer if we didn't advocate that simple key=value on one line was a bad practice in a book when it conflicts with the core docs, or that alternatively we should encouragestructured args versus splitting on a line, since there's going to a point where that's needed.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/9cfed224-bd34-400f-9ec2-766e80979e0d%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/GfJBkzuTTNM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/52f445bf-3dbc-4861-8e81-0d6000c65d39%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/GfJBkzuTTNM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJQqANcV-w0Sp%2BfgoDawZ0zxR%2BYefefb0WHqRCx3Rg5_PFLBqw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/b7041511-68a4-4132-b771-3347b2941c37%40googlegroups.com.