[10:50] * Chipaca decides it's time for more coffee [10:50] * bthomas resisting the urge to caffinate [10:51] * Chipaca laughs [10:51] there's 75mg of caffeine in my _hydration_ tablets [10:52] wow. coffee and tea are dehydrating though [10:52] on the other hand, there's 0mg of caffeine in beer [10:53] *most beer [10:53] who needs caffeine when you have beer. algthough I prefer some good port wine. [10:53] * Chipaca wonders about starboard wine [10:53] Cockburns fine tawny is very soomth [10:54] * bthomas googles starboard wine [10:55] * Chipaca ⇝ coffee [11:12] ¡Muy buenos días a todos! [11:13] Chipaca, is travis your friend today? [11:13] facubatista: travis is an enemy with benefits [11:13] jajaja [11:14] नमस्ते facubatista [11:14] hola bthomas [11:14] facubatista: hoping for a review from jаm and then we're done [11:15] * Chipaca points out 'jаm' is using a homoglyph because it's early [12:13] JoseMasson: buen día! [12:13] Buen día! [12:36] I think I'm going to step out and get lunch [13:57] http://ops.rtfd.io/ is returning 503 service unavailable [13:59] Chipaca: facubatista Have you tried using your IDE to access operator framework documentation. I use Emacs with Elpy. When I try to access the documentation (C-c C-d) I get a nearly blank page. I think this may be because we are not tying in the class and module level docs correctly into the package level but I am not sure. Any way I will just create a ticket for this now as I am still busy with the refactoring. [14:02] bthomas, regarding RTFD, it looks a problem on their side? [14:02] indeed [14:03] bthomas, regarding proper docs building/packaging/something, thanks for the issue [14:04] Chipaca, how are we coming regarding rollout? [14:04] facubatista: waiting for a review on #440 [14:04] PR #440: Set sys.breakpointhook in main instead of Framework.__init__ [14:04] facubatista: hopefully from jam 🙂 [14:05] Issue operator#441 opened: Link docstrings to package level [14:06] ack [14:06] * bthomas needs that coffee now [14:09] about 'ops' being almost blank: imho, we should make it so that 'ops' is all you need to import for making a 'basic' charm [14:10] i.e. everything we think is needed for just a charm (as opposed to a reusable component or extension of ops) should be doable by doing 'import ops' (or more likely 'from ops import x') [14:10] ie CharmBase, and main, and the statuses, and … etc [14:10] so people don't have to guess where inside ops the thing is defined [14:10] (which would also be nice to refactor at some point) [14:18] Chipaca: I like that ^ idea [14:19] * bthomas is jittery will at that coffee [14:27] bthomas: rtfd is back [14:27] thanks. [14:28] Just to be clear ops documentation is accessible if you look at any particular function or class but not if you look at the whole package. [14:30] bthomas: and if you look at a module? [14:30] bthomas: e.g. ops.testing [14:31] Chipaca: still blank : both import ops.framework and from ops import framework [14:31] bthomas: not even "The Operator Framework infrastructure."? [14:32] Chipaca: only that [14:32] I mean that is the only thing that is shown [14:32] bthomas: can you show me an example of something that shows more than just the toplevel docstring? [14:33] Chipaca: on the line from ops.charm import CharmBase , if i put the point on CharmBase and C-c C-d then I do get the docstring for CharmBase [14:50] bthomas: FWIW it sounds to me like C-c C-d is less helpful than python's builtin help() which i didn't think was a low bar [14:53] Chipaca: indeed just tried python's help(ops), and it does give more, in particular a list of modules. For comparison I also did import json and help(json) and C-c C-d on json, both give the same output. [14:53] right, that's a good docstring there [14:53] good one [14:53] otoh, json doesn't have submodules [14:53] true [14:54] we should look at some other stdlib [14:54] picking multiprocessing at random [14:54] urllib package level is quite sparse [14:55] multiprocessing is quite extensive [14:55] bthomas: in C-c C-d? [14:56] Chipaca: C-c C-d is extensive for multiprocessing [14:56] very strange [14:56] what is it doing? [14:56] because the docstring itself is empty [14:56] i installed elpy here to look into this also [14:57] nice, what are you using otherwise if not elpy, python-mode ? [14:57] oooh, looks like it uses pydoc.docmodule [15:02] Chipaca: I wonder if __all__ needs to be in ops/__init__.py and that will make it pickup and collate module level docstrings. [15:14] hah [15:15] so there's inspect.getdoc [15:15] that, if the module has *no docstring*, calls inspect._finddoc [15:15] interesting was not familiar with inspect.getdoc [15:17] bah, no, for modules _finddoc does nothing [15:17] Just to emphasise for multiprocessing both python help() and C-c C-d produce the same result [15:19] The only difference I can see between help() and C-c C-d is help() in some cases just lists the modules (without any module or lower level docs collated) where as in those case C-c C-d shows nothing. [15:20] bthomas: look what happens to C-c C-d if you delete the module-level docstring entirely [15:20] bthomas: i.e. if you edit __init__.py and delete the docstring [15:23] Chipaca: Indeed after deleting the one line docstring from ops/__init__.py I do see the list of modules (as shown by help()) and the license (placed under "DESCRIPTION" !) . [15:23] using C-c C-d [15:43] bthomas, here's the busy loop replacement PR: https://github.com/canonical/elasticsearch-operator/pull/23 [15:43] Review much appreciated :) [15:56] having a look [16:00] ah, dang, jam is away today [16:00] hmm [16:00] justinclark: care to review #440 ? [16:00] PR #440: Set sys.breakpointhook in main instead of Framework.__init__ [16:01] Chipaca, Yep - I'll look now. [16:01] thanks! [16:01] * Chipaca takes a short break [16:59] Chipaca - just approved #440. Though I fear I'm not as opinionated as jam would be on this. [16:59] PR #440: Set sys.breakpointhook in main instead of Framework.__init__ [16:59] justinclark: we can always fix it in post :-p [17:00] Issue operator#421 closed: breakpoint handlers unconditionally installed on framework initialization [17:00] PR operator#440 closed: Set sys.breakpointhook in main instead of Framework.__init__ [17:01] oh drat i forgot about #424 [17:01] PR #424: Added docstrings checks [17:01] * Chipaca hugs facubatista [17:07] yeah, i'm running tests locally and going to merge that by hand because travis is stupid slow again [17:08] PR operator#424 closed: Added docstrings checks === ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 1.0.0 || charmcraft 0.5.0 [17:32] facubatista: ^ [17:51] Chipaca, rocanrol [17:52] Chipaca, remote building now [18:00] EOW for me [18:00] have a great weekend all! [18:00] don't party _too_ hard [18:03] justinclark: I am not going to be able to finish your PR review today. I will leave only one half backed possibliy poorly thoughtout comment for you to mull over the weekend. But I will pick it up on monday along with review changes for Prometheus. Hope this is ok ? [18:03] * bthomas is hungry [18:05] bthomas, sounds good. No problem at all. [21:41] * facubatista eods and eows, will surely release on Monday...