At this point (and likely for some time, maybe forever?) there is no formal specification/best practices listing for Ansible, and that's both a blessing and a curse. It's nice to say "this way is the best", but it also means that there's less freedom to use a style that fits your needs.
I'll be writing up a blog post soon (and adding the info to Ansible for DevOps in a Best Practices appendix) summarizing these different styles, and showing why I use the one I use—but also mentioning why it is probably not for everyone. I think the discussion in this thread's been incredibly helpful, and I'm glad Michael gave some of his reasons for preferring the params-on-one-line approach. I think it also has to do with how much time an individual spends more on the 'dev' side or the 'ops' side of the devops equation—it seems to me people with more of an ops/get-it-done approach favor terseness, while people more on the dev/purist side prefer rigid syntax, multiline for VCS/diff ease, and structure rather than freedom. (All generalizations, I know... but that's my experience :). Now, how about we argue about ordering of parameters? apt: pkg=name state=installed update_cache=yes vs. apt: update_cache=yes pkg=name state=installed (Hopefully the sarcasm is obvious here... but people have spent a lot of time bikeshedding on things like alphabetical ordering of CSS properties <https://www.drupal.org/node/802930>, and we don't need to bog down adoption of Ansible by being too pedantic about YAML syntax :). -Jeff On Thursday, August 28, 2014 11:34:27 AM UTC-5, Patrick Heeney wrote: > > I used the second style present by Jeff which involved apt: > format. At > one time, I don't know how long ago this was in the ansible docs as a > coding style. > > Even with the widest screens available it is very difficult to read > everything on one line. For version control as mentioned it is also a lot > easier to break it up. > > Take for example this playbook of mine: > https://github.com/protobox/protobox/blob/master/lib/ansible/applications/wordpress/tasks/application.yml > > It would be difficult to read a lot of those on a single line. The > drawback if this approach recently broke in ansible 1.6-1.7ish and took a > week or more > to be resolved. This required some hacking and back porting to an earlier > version to get working again. Luckily this was fixed and now unit tested so > it > should not happen again. However it is something to be aware of that there > are more official "syntaxes" that are supported by ansible. > > Overall I wish the project had a coding style guide that helps show > different usages for teams to decide. I for one did not know about the 3rd > format which is apt: pkg:. > > On Tuesday, August 26, 2014 6:40:30 AM UTC-7, Jeff Geerling wrote: >> >> Haha, believe me, I've tried a lot of tricks to see how much I could fit >> on a line :) >> >> On Monday, August 25, 2014 4:25:05 PM UTC-5, Michael DeHaan wrote: >>> >>> No 4px fonts? >>> >>> >>> >>> >>> On Mon, Aug 25, 2014 at 4:36 PM, Jeff Geerling <[email protected]> >>> wrote: >>> >>>> Also, one other thing I forgot to mention, LeanPub in particular, and >>>> most other publishers as well, has a hard limit of 78-81 characters per >>>> line for an 8x10 book, so parameter-per-line works out for that nicely. >>>> Otherwise I'd have arbitrary line breaks all over my code examples, and >>>> that makes the book incredibly difficult to read. >>>> >>>> Until book layouts are fully fluid, that's going to be an issue with >>>> any published work. >>>> >>>> -Jeff >>>> >>>> >>>> On Monday, August 25, 2014 3:33:58 PM UTC-5, Jeff Geerling wrote: >>>>> >>>>> >>>>> >>>>> On Monday, August 25, 2014 3:25:04 PM UTC-5, Michael DeHaan wrote: >>>>>> >>>>>> 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 encourage >>>>>> structured args versus splitting on a line, since there's going to a >>>>>> point where that's needed. >>>>>> >>>>> >>>>> Exactly why I'm asking here :) >>>>> >>>>> I want to present a style that I use and like, but make sure to not >>>>> say "this is the Ansible way", but rather, "here are the common ways >>>>> tasks >>>>> are written... I prefer *this* style (whatever it turns out to be... >>>>> I'm still not completely sold on any one way as a general rule) for >>>>> reasons >>>>> X, Y, and Z, but if you find that one of these other methods works better >>>>> for you or your team, please use it. The important thing is to use a >>>>> consistent style that helps you be productive and write effective >>>>> playbooks... >>>>> >>>>> Something along those lines, but basically, since there is no official >>>>> style guide for Ansible (just examples in docs and the examples repos), >>>>> and >>>>> since I see about a hundred different styles in the wild, I want to be >>>>> comprehensive but not lead people astray. >>>>> >>>> -- >>>> 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/9cfed224-bd34-400f-9ec2-766e80979e0d%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/ansible-project/9cfed224-bd34-400f-9ec2-766e80979e0d%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/52f445bf-3dbc-4861-8e81-0d6000c65d39%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
