=== max__ is now known as Guest14293 [04:43] o/ [05:41] morning Dmitrii-Sh [06:35] morning jam [06:36] regarding https://github.com/canonical/operator/pull/216#discussion_r405455364 - we'll need to change our copyright header checks then [06:37] as for serialization, I converted the interface code to use json instead https://github.com/canonical/operator/pull/216/commits/68152461b5b104ccf4aaea3c04ea36e9d1fd5c7b [06:38] Dmitrii-Sh, indeed, it really depends how we want to do it as a project, and then update the source checks, etc to match that. [06:38] I think I clarified that my preference is to keep Copyright as a comment and put the docstring after copyright comment [06:38] which wouldn't require changes [06:48] jam: ok, I reverted the change. Might be good to discuss during the standup [08:24] Good morning all [08:25] morning [08:32] gooood morning team! [08:45] * jam steps away for lunch, bbaib [08:48] 'be back after i burp' 👍 [09:47] I thought I was the one that made up backronyms. I did realize once I hit submit that it was a typo, wasn't sure it was worth a second message :) [10:22] I just came across this https://www.theonion.com/nasa-launches-vengeance-rover-to-pay-back-mars-for-kill-1842750166 [10:31] Dmitrii-Sh, Chipaca : thoughts on parameter formatting. 'git annotate' says that I use ":param foo: description" style, while the two of you have used more "foo -- description" style. [10:31] we should probably get shared agreement on that style (possibly based on what Sphinx/readthedocs renders) [10:31] jam: agreed [10:31] s/we should probably/we need to get/ [10:31] so, questions [10:31] do we want to use python type annotations or not? [10:32] (if we did, we could then use mypy to do static analysis while not requiring it to run) [10:32] I've never used them, my primary Python time was in the 2.* era. AIUI they are just documentation as well, right? [10:32] eg, not actually enforced. [10:32] right, except mypy can check for them [10:32] ie you can do static analysis [10:32] I don't have enough experience with them to know whether they feel good or feel like noise. [10:33] when running with plain python, they're just metadata [10:33] to me they feel more natural than the :type: docstrings [10:33] but I don't have a super-strong preference :) [10:34] let's talk about it on tuesday when facu is back [10:34] facu and myself, that is :) [10:34] Given the language has built-in support for them, I'd tend to go with that over :type:, It also depends heavily on how well supported they are in editors [10:34] i'll set up a meeting so we remember [10:34] but PyCharm seems to support either. [10:34] sphinx supports either also (with a plugin) [10:35] i need to check if readthedocs supports that plugin but it should (and i have a friend working on the readthedocs backend so i might be able to influence that if they don't) [10:35] My main concern with "foo --" is that it is missing the "bulleted list" indicator. (start of new section is after the section has started) [10:37] jam: 1 sec [10:37] jam: http://www.sphinx-doc.org/en/master/usage/extensions/napoleon.html [10:38] jam: I'd prefer either of those styles (google or numpy) to the default rst style [10:38] jam: in any case 'foo --' is wrong :) [10:38] jam: and, 1 further sec for me to find the other extension [10:39] Chipaca, interestingly, their statement "Compare the jumble above to this alternative". I actually find it easier to read the "jumble" but that is likely just lots of usage of that style. :) [10:39] I can imagine that practice with an alternative will similarly improve my ability to read it. [10:39] jam: https://github.com/agronholm/sphinx-autodoc-typehints would be the extension that gets type from the annotation, and it supports napoleon also [10:40] for some reason I don't like "foo (type):" [10:40] I would have preferred it "foo: (type)" [10:40] I'm not a big fan of the :type: etc notation.. I've never seen it being worth the cost of having to write and read it, compared to normal English text in the summary [10:40] In that, I prefer Numpy, though it feels rather spaced out. [10:41] We generally end up re-stating the type in the sentence anyway [10:41] jam: note that with the typehints thing we'd just write foo: in the google style [10:41] :type:FooBar: The FooBar used to process it. [10:42] maybe we should write them out in full for a single realistic docstring for the meeting tuesday [10:42] i'll get on that after finishing dispatch support [10:42] +1 [10:42] Thanks for that [10:42] Chipaca, sounds like some nice examples to have on hand [10:43] Are we skipping the standup today? [10:43] we can do it on IRC just to make sure we're aware of what we're doing [10:43] Well.. :) [10:43] :-D [10:44] but, no, i don't think we should (it's just facu that's away) [10:44] i did delete it and then re-created it because i thought we'd do the bug revue today (but facu's away) [10:44] otoh i don't mind doing it on irc because introvert [10:49] I don't have it in my calendar.. if it's just Facundo out, we should do it [10:50] so the weekly operator sync meeting that collided on Tues got moved to Friday evening.... [10:50] jam: yeap [10:51] jam: don't worry about it [10:51] I was going to say that it isn't a time that I think I'll be attending regularly. [10:53] Best time for regular weekly meetings.. Friday evening.. [10:53] I've emailed Anthony about it being sub-ideal, we'll see [10:53] meanwhile, don't fret it [10:56] Better than that only if it was a Good Friday.. [10:59] they're all good fridays bront [11:10] oh drat 12pm and i didn't have mah mid-morning protein [11:10] lunch is gonna be a big thing [12:29] * jam heads to help my son study Spanish [13:08] I think this is relevant to our interests: https://mobile.twitter.com/fasterthanlime/status/1248025337235210243 [13:09] Weeeeee [13:33] niemeyer, Dmitrii-Sh, jam, 👋 [13:33] o/ [13:33] I came back from getting a cup of tea to find my desktop wouldn't un-map the lock screen [13:33] annoying [13:33] We're in the standup.. [13:33] omw [13:33] Chipaca, Dmitrii-Sh https://meet.google.com/fqw-mdqc-dsf [13:33] ta [13:52] https://github.com/canonical/operator/pull/221 reviewed [13:52] 'osp' is that supposed to be 'ops' ? [13:55] Hi, anybody can take a quick read to this pastebin to see what I'm doing that wrong settinga relation data? https://pastebin.canonical.com/p/sJGfT8Cx7v/ [13:56] pekkari, you are setting "admin_url" to a tuple (url,) is that intended? [13:57] jam: no those commas are not intended, I was trying to set a full dictionary first, and then moved to key by key assignment, thanks for the hint [13:57] pekkari, the other bug is that "event.unit" is the *remote* unit whose data has changed [13:57] pekkari, you're not allowed to write to the remote unit's data [13:58] pekkari, you want event.relation.data[self.model.unit] [13:58] pekkari, event.relation.data[event.unit] is to read the data that the remote side is telling you about during relation-changed [13:58] I see, yeah, I was suspecting it was a newbie issue here [13:59] thanks jam! I'll test it this way [13:59] jam: thanks for the review [14:00] jam: the "run the hook _as well_" was not what I had understood... but that's ok :) [14:01] Chipaca, so we had a number of discussions about it, where I ended up was that the operator framework already likes to have multiple event handlers [14:01] lots of things can listen for 'install' [14:01] the hooks/* is just another one of them [14:01] right, so that seems in tune with that [14:01] i'll fix [14:01] If you don't do that, then it ends up that dropping a shell script ends up breaking all the components that you're using [14:01] you say that like it's a bad thing [14:01] * Chipaca hides [14:02] Chipaca, no worries, I was originally more in favor of what you implemented. It was when I realized the multi-event thing that it clicked in my head. [14:02] jam: and yes i seem to have been in more of a hurry than needed when writing the commit message, will fix that also [14:15] I think I'm going to go for a run now, and return to this after [14:26] * Chipaca goes [16:07] #218 [16:07] PR #218: Add relation-created events [16:26] #waat [16:27] cockroachdb-operator#1 [16:27] PR cockroachdb-operator#1: initial cockroachdb-operator charm for review [16:32] reworked #212 [16:32] PR #212: Harness: do not emit extra relation changed events [16:32] nice ^ [16:33] thanks for making mup_ work niemeyer [16:34] My pleasure.. this is still not 100% online as it's running in my laptop for now, but hopefully next week I can finish the migration [16:35] This is a separate instance from mup.. eventually mup will die and this will get renamed to it [17:14] OK guys, i'm off, mostly. Will checkback from time to time to poke at things, but other than that, see you Tuesday! [17:26] Chipaca: Have a good evening and a good holiday [17:26] i've got a slow-cooking pork shoulder going since breakfast time [17:26] the whole house smells of it [17:26] so it's off to a good start i reckon :-) [17:27] Poor neighbors :P [17:27] :-D