19:00:25 <jillr> #startmeeting ansible core irc public meeting
19:00:25 <zodbot> Meeting started Tue Sep 10 19:00:25 2019 UTC.
19:00:25 <zodbot> This meeting is logged and archived in a public location.
19:00:25 <zodbot> The chair is jillr. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:25 <zodbot> The meeting name has been set to 'ansible_core_irc_public_meeting'
19:01:01 <jillr> #topic https://github.com/ansible/ansible/pull/53595
19:01:55 <jillr> we didnt have enough of us last week to discuss this one, cc gundalow
19:03:21 * sdoran reading
19:06:05 <sdoran> Oof, can of worms.
19:06:11 <jillr> I'm in favor of consistency, and generally prefer the bracket notation.
19:06:20 <jillr> but yeah, not a small undertaking
19:07:02 <felixfontein> I still prefer the dot notation, but I can live with official docs using the array notation :)
19:07:06 <sdoran> Though I understand the reason bracket notation is better, I'm with dag in that the do notation is easier to read. It also makes for an easier transition: `ansible_hostname` --> `ansible_facts.hostname`.
19:07:16 <sdoran> *dot
19:07:45 <sdoran> I don't think we should mix them, so if an example is using bracket notation, keep it until the end.
19:08:08 <jillr> whereas I have a harder time reading that when I'm deep in a lengthy review of something - is that a dot? did my eyes even see the tiny character?  *squint*
19:08:16 <sdoran> But for casual use and most examples, I prefer dot notation.
19:08:56 <sdoran> And I think the dot notation is more user friendly and feels less like programming (even though it totally is).
19:09:05 <jillr> I can see how some folks would find it less visually "cluttered" though
19:09:20 <jillr> YAML is not a programming language  :)
19:09:25 <sdoran> Yes. And less typing for those not accustomed to hitting those keys a lot.
19:09:53 <felixfontein> jillr: and jinja templating is not YAML :)
19:10:11 <jillr> felixfontein: see also: Jinja is not a programming language!
19:10:34 <jillr> yet here we find ourselves
19:11:03 <felixfontein> well, it has for loops and if statements. it's probably not turing complete, though, but I wouldn't bet on that :)
19:12:40 <jillr> ok so, we're +2 dot and +1 [], right?  excluding the comments in the PR, which isnt enough for quorum again
19:13:29 <felixfontein> bcoca's argument (https://github.com/ansible/ansible/pull/53595#issuecomment-472038072) reminds me of the group name discussion... I can see that it makes support easier, though having quotes inside quotes ("{{ ansible_facts['whatever'] }}") makes it more complicated again - you have to be sure to use the "correct" quotes on each level
19:13:33 <jhawkesworth> remind me, is ansible_facts. ns a place where custom facts can go?
19:13:48 <felixfontein> I think all facts end up in there
19:14:22 <jhawkesworth> hmm, so bcoca's point about calling method instead of retrieving the key value could potentially occur.
19:14:26 <felixfontein> I don't know where this special-case handling of `ansible_facts.name` vs. `ansible_name` comes from, though
19:14:28 <sdoran> felixfontein: I plan to tackle the invalid group characters problem.
19:14:42 <sdoran> That's a separate discussion, though.
19:14:56 <felixfontein> jhawkesworth: and that users sometimes use invalid Python identifiers and end up with var.something-invalid, which won't work
19:15:10 <felixfontein> sdoran: good luck :)
19:15:13 <sdoran> Dot notation is great until it isn't.
19:15:15 <jhawkesworth> so ['syntax'] is safest
19:15:28 * jhawkesworth likes examples that work
19:15:28 <sdoran> Yes, but not the friendliest.
19:15:41 <jhawkesworth> yeah its a faff to type (on my keyboard anyway)
19:15:53 <felixfontein> also people have to make sure they don't use the same quotation marks for the whole string and inside the jinja template
19:16:48 <jhawkesworth> yeah it all has to be properly wrapped up
19:16:48 <felixfontein> jhawkesworth: I switched to en_US layout (from de_DE) a looong time ago when I was still mostly programming in C/C++, {}[] is so much easier to type with en_US...
19:18:13 * jillr looks at DE key layout, oh yuck. yeah I would probably use dot more too then  :)
19:18:47 <felixfontein> hehe yes :)
19:19:08 <jillr> a good quesiton then would be is i18n a sufficient driver to consider for docs?
19:19:09 <jhawkesworth> uk keyboard pretty to close us keyboard layout but [''] is 4 keystrokes and . is 1
19:19:43 <felixfontein> [""] is even worse
19:19:45 <jillr> I honestly dont know how we would weight that, but - should we?
19:19:48 <Goneri> I've the feeling the discussion is going a bit too far :thinking:
19:20:48 <jillr> I dont think we'll solve it today, just asking our non-US folks if this is a factor that should be on our radar for these types of things
19:21:10 <jillr> that would have to be it's own seperate issue and topic
19:21:37 <sdoran> Yes, we're overthinking this a bit.
19:22:00 <felixfontein> I don't see that there's a silver bullet anyway... I'm happy as at least somewhere in the docs, both ways are described even if all (other) examples stick to one way
19:22:03 <sdoran> I vote for dot notation with `ansible_facts.foo` unless bracket notation is already in use or makes sense.
19:22:11 <sdoran> Keep it simple unless it needs to be more complicated.
19:22:28 <sdoran> I like simplicity as the guiding principle.
19:22:38 <sdoran> Use dot notation until you can't. :)
19:22:45 <felixfontein> might be harder to explain that to newbies, though :)
19:23:02 <sdoran> Right, but progressive disclosure.
19:23:10 <felixfontein> especially the ones which totally have no idea what to do when dot notation suddenly stops working (and can't interpret the error messages they're getting)
19:23:32 <jillr> ok so: a) prefer dot notation with `ansible_facts.foo` until you cant  b) prefer bracket notation
19:23:47 <sdoran> That's the point at which they can engage the community for help, or we could put a helpful (and searchable) note in the docs.
19:23:55 <jhawkesworth> good point, I'd be happier with . notation if sure the error message would always help you re-write
19:24:18 <jhawkesworth> best if users can help themselves, quickest feedback you'll ever get is from the computer itself after all
19:24:26 <felixfontein> the error message for .keys will probably never be helpful enough
19:24:27 <jhawkesworth> but .. can of worms
19:24:35 <felixfontein> huge can of worms :)
19:25:16 <felixfontein> hi dag!
19:26:09 <cyberpear> there's hopefully no ansible_facts named w/ dashes, so for this case, dot should be fine, I think
19:26:34 <jhawkesworth> as long as examples work I am +0 regarding . or [''] syntax really.
19:27:11 <jillr> then: a) prefer dot notation with `ansible_facts.foo` until you cant  b) prefer bracket notation  c) YOLO whatever works?  :)
19:27:36 <cyberpear> (but I don't really care what the docs say as long as no one tries to take away dot notation, and no one tries to hide dot notation behind a non-default config option)
19:27:50 <jhawkesworth> given it seems unlikely keys error message would ever be helpful, next best thing would be a 'gotchas section' in the docs that explains exactly when you can't use . (which to be fair doesn't just apply to ansible_facts. )
19:28:04 <bcoca> its already there and in FAQ
19:28:20 <bcoca> and i tried getting docs change in docs meeting, was shot down by overwhelming majority
19:28:31 * jhawkesworth hasn't read FAQ for a little while
19:28:51 <bcoca> also this is not a support issue, it 'comes from support' but it is a user experience issue
19:29:04 <bcoca> its bad when users try to combine 2 features and get a bomb
19:29:12 <jillr> bcoca: was that docs meeting regarding the PR in topic or just a related conversation?
19:29:42 <bcoca> it led to the PR
19:29:56 <bcoca> and related one
19:30:06 <jillr> ahk, /me looking for meet logs
19:30:21 <bcoca> was a few months ago ... cannot recall exactly
19:31:05 <jhawkesworth> https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#ansible-supports-dot-notation-and-array-notation-for-variables-which-notation-should-i-use is pretty clear
19:31:17 <bcoca> and its been there for a LONG time
19:31:23 <bcoca> people still hit it constantly
19:34:15 <jillr> I'm not finding the previous convo yet, giving up for now
19:34:52 <jillr> so we can: vote on the given options, just point to the docs we already have, do we have a 3rd option?
19:35:25 <jhawkesworth> i doubt improving jinja's . implementation is an option
19:35:37 <bcoca> actually that is only option i have left
19:35:39 <jillr> jhawkesworth: PRs welcome  :)
19:35:43 <felixfontein> I don't think it's possible to properly "improve" it
19:35:51 <bcoca> jillr: not our project .. but they do welcome PRs
19:36:00 <jillr> bcoca: that's what I meant
19:36:02 <felixfontein> because there are valid use cases for all notations which cause problems
19:36:11 <bcoca> felixfontein: kind of, the problem is the identifier handling, needs rewriting from top down
19:36:37 <jtanner> jinja's dot notation is a convenience for folks using it to template html files, not to serve the ansible user base's needs, except where we can justify it for the broader audience
19:36:39 <jhawkesworth> ... and you don't want me doing that in powershell ;-)
19:36:43 <bcoca> yes, that is why you need to check validity against each option
19:39:58 <jillr> ok so, hard problem is mostly a hard problem in jinja which we're not going to fix here. how, then, are we going to respond/react to it for our docs purposes and in particular for the current topic?
19:41:29 <bcoca> idk, every option has a legion of detractors, at this point im about to rent an arena and let them fight it out
19:43:56 <jhawkesworth> as dag pointed out, if we knew where we wanted to go with this it would be easier to react.
19:44:12 <jillr> I hate to table this just to keep talking circles around it again another day but we've used most of our time for this meeting already today and don't have any resolution
19:44:58 <jillr> is there some other way we can approach this topic that might get more results?
19:45:09 <jhawkesworth> I don't know enough about parsing or if this would even be possible, but inventing an ansible-specific syntax, perhaps something like thing%key
19:45:13 <jillr> I'm not saying I can think of one, just in the interest of moving forward somehow
19:45:15 <jhawkesworth> ugly i know
19:45:42 <jtanner> i scrolled up, but i'm not sure i know what problem is being proposed
19:45:47 <bcoca> any of those would require patching jinja2
19:45:51 <jillr> I'm -1 on inventing our own jinja-like dsl, if I follow you correctly
19:45:55 <felixfontein> % is the modulo operator, and might also works for string formatting in jinja2 (as in Python)
19:45:56 <bcoca> jtanner:  . notation unfriendlyness to -
19:46:03 <jillr> jtanner: https://github.com/ansible/ansible/pull/53595
19:46:31 <jhawkesworth> yeah its ugly, but was looking for available punctuation on my keyboard
19:46:40 <jtanner> i don't see any dot notation in that PR, hence the confusion
19:46:41 <jhawkesworth> its basically making it a hard problem again
19:46:56 <jtanner> oh ... the PR comments
19:47:00 <jhawkesworth> dot notation sugested in comments
19:47:06 <jtanner> <lightulb on>
19:47:06 <felixfontein> jhawkesworth: I guess @ is one of the few things still available
19:48:02 <jillr> jhawkesworth: € ¥ and £ should be free!  ;)
19:48:38 <jhawkesworth> Yep I have `and ¬ on this keyboard too.
19:48:58 <jillr> to the topic at hand though, it seems like c) is "leave docs things the way they are, with mixed examples"
19:49:02 <felixfontein> I'm glad I have a compose key
19:49:11 <jillr> given the previous: a) prefer dot notation with `ansible_facts.foo` until you cant  b) prefer bracket notation
19:49:13 <jtanner> ¬ ... for all those boolean logic proofs we do every day
19:49:25 <sivel> +1 for C
19:49:58 <felixfontein> or c'): leave docs things the way they are *for now*, with mixed examples :)
19:50:03 <jtanner> C++
19:50:06 <sivel> it's not enforceable, so I don't see a reason to waste time on it
19:50:09 <jillr> jtanner: lol
19:50:29 <shertel> I'm fine with advertising only brackets or leaving things mixed, don't especially have a preference.
19:50:54 * shertel will continue using . when it makes sense regardless
19:51:09 <bcoca> need to find logs, but in last meeting i was told 'if you remove . notation from docs i'll stop using ansible and new users will not pick it up, its what makes things easy'
19:51:11 <jillr> I'm also 0.5 B  and  0.5 C
19:51:53 <jtanner> if anything, i think we could have a doc entry to explain how jinja dot notation works under the covers and point to that whenever someone complains
19:52:04 <jtanner> but that is separate from this current decisino
19:52:09 <felixfontein> bcoca: I think I remember the discussion, and I think it was not *that* extreme :)
19:52:10 <jtanner> decision*
19:52:12 <bcoca> jtanner: already documented
19:52:19 <shertel> I think we do, right? Maybe in valid variable docs.
19:52:21 <jillr> jtanner: https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#ansible-supports-dot-notation-and-array-notation-for-variables-which-notation-should-i-use
19:52:32 <shertel> ^ oh
19:52:36 <bcoca> felixfontein: iirc, it was more extreeme than that
19:52:53 <bcoca> documentation is not the issue, people reading it ....
19:52:58 <jtanner> hrm, doesn't explain how jinja basically try/excepts the attribute then checks for key
19:53:16 <jtanner> or vice versa, which is why you get attr errors on missing keys
19:53:21 <bcoca> that woudl be over the top for most users that dont understand the diff between this.key and this['key']
19:53:31 <felixfontein> bcoca: maybe also my memories are a bit clouded...
19:54:05 <jillr> I currently have: A0 B1 (based on 2 halves) C3.
19:54:20 <jhawkesworth> . is very familiar, not just to python programmers
19:54:47 <jhawkesworth> I think I'm C given sivel's point that its unenforceable
19:55:21 <felixfontein> I think I'm also mostly C
19:55:33 <jillr> (does C mean we're closing that PR?)
19:56:11 <bcoca> its enforceable, but we either loose . notation or - in names
19:56:35 <bcoca> its not enforcable to handle combination, that requires patching jinja2 and its not a small patch, its pretty involved
19:57:17 <felixfontein> I'm -1 on making it enforcable
19:58:10 <jhawkesworth> it will drift over time if not enforced I suppose.
19:59:04 <jillr> So that's A0 B1 (based on 2 halves) C5, and I'm going to close 53595 with a summary of why we dont think we should be prescriptive on this particular can of worms in docs.
20:00:01 <jhawkesworth> yeah its not a great situation.  But have to accept that ansible is standing on jinja's shoulders which gives us . which is great except for the edge cases
20:01:06 <jillr> thanks folks
20:01:11 <jillr> #endmeeting