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 <[email protected] > <javascript:>> 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. >
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. > > >> >> - 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. > Makes sense, and I will be moving over most of my playbooks to this form (I used to use the > method more often, since I would type out the task on one line, then break it up by parameter afterwards... now I'm starting with parameter-per-line and it's easier to use this method). > > >> >> 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. > That's the plugin I'm using, and it makes --syntax-check almost redundant, since it makes any YAML-specific errors pretty glaring. Especially for someone newer to YAML, I'd highly recommend finding a way to write it with syntax highlighting. > > >> >> 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 it's best to find ways to not have to use extra options with commands/shell commands, but it seems I always have to drop down to that level once or twice for a given playbook, and it's easier for me to digest what's going on if it's on multiple lines (not saying it's best, or everyone should do it...). But for consistency's sake, I can see just using one-line here. > > > >> >> 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. > 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 [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/37a5f704-409d-4e0a-98b8-9c0ad290a264%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
