On Mon, Aug 25, 2014 at 9:49 AM, Jeff Geerling <[email protected]>
wrote:
> In the documentation, and for terseness, many task examples are given like:
>
> - apt: pkg=package_name state=installed update_cache=yes
>
> However, 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_name
> state=installed
> update_cache=yes
>
I 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_name
> state: installed
> update_cache: yes
>
This 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 1
> creates=/some/path/here
> chdir=/home/johndoe
>
Keeping 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 1
> args:
> creates: /some/path/here
>
chdir: /home/johndoe
>
This 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.
> --
> 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 [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/52876e78-8c0c-455b-8c81-6a3ebc5a50ce%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/52876e78-8c0c-455b-8c81-6a3ebc5a50ce%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgw10sY%2B_pVLyHJgTu4KbLr%2B%3D%2BGtX-%2BMvbgrCCR1YRkd%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
