| mup_ | Issue operator#256 opened: Upgrading charm does not recreate the hook symlinks <Created by xavpaice> <https://github.com/canonical/operator/issues/256> | 01:21 |
|---|---|---|
| mup_ | Issue operator#257 opened: When install hook fails no other hook symlinks are created <Created by woutervb> <https://github.com/canonical/operator/issues/257> | 01:33 |
| jam | morning all | 05:06 |
| MarkMaglana | o/ | 05:14 |
| MarkMaglana | jam: sent you an email. i should have checked your timezone first before suggesting those times. :) | 05:16 |
| jam | hi MarkMaglana, I saw you're email, still working out what times are going to work well. I'd like to have more of the team around, but if its just us we can make that work. | 05:17 |
| MarkMaglana | it'd be good to have more of the team around to get the most feedback. i'll wait for your response then. | 05:18 |
| mup_ | Issue operator#241 closed: _TestingModelBackend incorrectly raises KeyError on missing relation <Created by gnuoy> <Closed by jameinel> <https://github.com/canonical/operator/issues/241> | 07:15 |
| mup_ | PR operator#253 closed: Test harness no backend <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/253> | 07:15 |
| mup_ | PR operator#196 closed: Factor out the Harness changes for test_model.py <Created by jameinel> <Closed by jameinel> <https://github.com/canonical/operator/pull/196> | 07:40 |
| Chipaca | good moorning all! | 08:03 |
| jam | morning Chipaca | 08:07 |
| jam | I think https://github.com/canonical/operator/pull/252 follows the doc guidelines that we wanted, and the test suite is passing. | 08:08 |
| mup_ | PR #252: ops/testing.py: document Harness in Google style <Created by jameinel> <https://github.com/canonical/operator/pull/252> | 08:08 |
| Chipaca | jam: ah, you kicked travis into submission i see | 08:09 |
| jam | Chipaca, I merged master and fixed a collision, so it had to try again :) | 08:09 |
| Chipaca | yeah | 08:09 |
| Chipaca | sometimes it be dumb | 08:09 |
| jam | I don't know how to fix it without a push | 08:09 |
| jam | Logging into TravisCI seemed like it exposed more than I wanted to travis, so I wasn't sure if I wanted to do that | 08:10 |
| Chipaca | (actually travis tries to ping back with all the authenticated users it knows of, but rate limiting is per org or something on the github side … at least that's what i remember from sitting next to travis guys at a snapcraft summit ages ago ) ) | 08:10 |
| Chipaca | jam: want me to generate the docs from that so we see what they look like? | 08:11 |
| jam | Chipaca, sure. It would be good to see if there are any problems | 08:11 |
| jam | ok. if I log into travis, it gives me a 'trigger build' option. | 08:12 |
| Chipaca | jam: some of these warnings might be of interest to you: https://pastebin.ubuntu.com/p/xdtSfn4TpR/ | 08:14 |
| Chipaca | jam: and the built docs: https://r.chipaca.com/docs/_build/html/123/ops.html#module-ops.testing | 08:16 |
| Chipaca | I'll make a branch with the conf.py and the toplevel rst's so you too can build them | 08:17 |
| Chipaca | (need to fix a warning about a duff rst first) | 08:17 |
| jam | Chipaca, so most of those are in 'charm.py' which I wasn't touching. The one about 'unknown enable_hooks' is interesting. Does it need to be 'self.enable_hooks' ? | 08:19 |
| jam | Chipaca, what are you using to generate the docs, so I can iterate? | 08:20 |
| Chipaca | jam: wrt how to iterate, i need to push a pr. The minimum you need is a docs/conf.py as the rest can be autogenerated at least until we lay things out better | 08:32 |
| Chipaca | wrt gnome shell eating up all my ram, i have a background on rotation, and some of the images are large, and gnome shell seems to not check whether the image fits before loading it | 08:34 |
| Chipaca | nor does it scale it down on input like you could ask imagemagick to | 08:34 |
| jam | interesting. seems easy to disable to at least get things working until your other machine comes back | 08:35 |
| Chipaca | (how large? iirc one of the images there i used to expose a bug in the 64 bit libjpeg for an image that wasn't representable in 32 bits...) | 08:35 |
| Chipaca | yeah, once i realised what was going on i did that :) | 08:35 |
| Chipaca | hence how i'm back | 08:35 |
| jam | image that wasn't representable in 32bits... sounds like a nice test | 08:39 |
| jam | Chipaca, you mentioned you use hexchat. I currently have a concern with it, that I'm not sure the fix. | 08:40 |
| jam | If someone mentions me in a channel, it highlights that channel in green | 08:40 |
| Chipaca | as i remember it, i had to compile my own libs to be able to stitch a pair of nasa photojournal images of earth | 08:40 |
| jam | However, it just marks a channel with a conversation as red | 08:40 |
| jam | but it does that for private messages as well | 08:40 |
| jam | any way to get it to use the same Green for private messages as though I was called out in a public channel? | 08:40 |
| Chipaca | jam: where is this colour? in the notifications themselves, or in hexchat? | 08:41 |
| jam | Chipaca, the tabs along the left where it lists the channel names | 08:41 |
| Chipaca | jam: isn't it 'new message' vs 'highlight' in the interface colours? | 08:42 |
| jam | so the issue is that if there is any new message in any channel, it goes red or blue (I haven't quite figured out when it usess which) | 08:45 |
| jam | but I want new messages in private chats to be treated like notifications in public chats | 08:46 |
| jam | Chipaca, eg, I idle in about 15 different rooms in case someone pings me, and I hear a ping when someone private messages me, but finding that tab is hard, because it is a sea of 'someone said something in this channel' | 08:47 |
| Chipaca | jam: i think my hexchat config is out of whack, because i've been fiddling with it for over 10 years (migrated it from xchat) | 08:51 |
| jam | :) | 08:51 |
| jam | Chipaca, testing your colors out | 08:52 |
| Chipaca | jam: and again please (in 10 seconds, also in PM please) | 08:53 |
| jam | 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 | 08:54 |
| jam | Chipaca ! | 08:54 |
| Chipaca | OK | 08:54 |
| Chipaca | so, the private message colour is set by settings -> preferences -> colours -> new message | 08:55 |
| Chipaca | the public highlight is _not_ 'highlight' in that same thing | 08:55 |
| Chipaca | it might be … spellcheck?? | 08:55 |
| Chipaca | let me confirm | 08:55 |
| Chipaca | jam: again please | 08:56 |
| jam | right, but isn't the "settings -> pref -> color -> new message" the same one that shows up for a channel where anyone speaks to anyone else? | 08:56 |
| jam | thats the difficulty | 08:56 |
| jam | private messages are 'targetted at me' though my name isn't mentioned | 08:56 |
| jam | at least, that's how it works in my head :) | 08:56 |
| Chipaca | i'd have to wait for somebody to say something in a different channel to answer that | 08:58 |
| Chipaca | people are quiet right now | 08:58 |
| jam | see private group chat for non targetted message | 08:58 |
| Chipaca | jam: that is indeed the same colour :-( | 08:59 |
| Chipaca | jam: which means | 08:59 |
| Chipaca | jam: you're probably going to have to go into 'text events' | 08:59 |
| Chipaca | and change %C28*%C29$3$1%C28*$t%O$2 to something that makes sense to you | 09:00 |
| jam | yeah, I'll just learn to love the same colors | 09:00 |
| jam | The other plugin I had in the past was one that would hide join/part messages except if the person was active recently | 09:00 |
| jam | which is relevant since you occasionally have to restart your machine in the middle of a conversation | 09:01 |
| jam | I seem to be able to hide them always, but that isn't quite what I want | 09:01 |
| jam | hm, looks like I can set it per window | 09:02 |
| jam | so at least large group chats don't have them. that's nice | 09:02 |
| Chipaca | jam: FWIW I *think* %CNN is a numbred colour in the above string, but in case it wasn't obvious i haven't dug much :) | 09:03 |
| Chipaca | anyway, now i want my old colours back | 09:03 |
| * Chipaca gets them | 09:03 | |
| jam | afaict, hexchat doesn't treat the events the way my brain does. Which is "if you're going to beep at me, color it green so I can find it" :) | 09:04 |
| * Chipaca takes notes about how jam's brain works | 09:09 | |
| jam | danger, danger, daaannn...geeeer | 09:10 |
| * Chipaca locks sends the notes to SCP for safekeeping | 09:13 | |
| Chipaca | s/locks// | 09:13 |
| Chipaca | jam: pushed the docs stuff | 09:42 |
| mup_ | PR operator#258 opened: docs: first pass at sphinx-built API docs <Created by chipaca> <https://github.com/canonical/operator/pull/258> | 09:42 |
| Chipaca | see? :-p | 09:42 |
| jam | todo_include_todos | 09:46 |
| jam | I should do that | 09:46 |
| Chipaca | jam: FWIW that lines up (contrary-wise) to what you and facu said about TODOs *not* being in the docs | 09:47 |
| Chipaca | as in, sure have a TODO in the docstring but don't show it in the API docs | 09:48 |
| Chipaca | that's the default, which that setting toggles | 09:48 |
| Chipaca | and you can then separately use it to generate a todo list | 09:48 |
| Chipaca | to be clear: todo_include_todos should be _false_ (the default) so that TODOs don't turn up in the API docs | 09:49 |
| Chipaca | also to be clear: the current index.rst sucks because it's just too big, but it's alright to get started imho | 09:50 |
| Chipaca | we can then split, sort, tidy, etc | 09:50 |
| Chipaca | hard to tidy with nothing | 09:50 |
| Chipaca | (or maybe too easy) | 09:50 |
| jam | its super lean | 09:51 |
| Chipaca | jam: ah, yes sorry i meant the doc it generates | 09:52 |
| Chipaca | it's a single page of everything | 09:52 |
| jam | I'm just saying nothing is very lean | 09:52 |
| Chipaca | ah :) yes | 09:52 |
| Chipaca | agile, also | 09:52 |
| jam | I haven't had a chance to render it locally yet | 09:52 |
| jam | trying to finish a quick commit and then i'll review | 09:52 |
| Chipaca | jam: i can also set up rtd to generate it for you, once this is on master | 09:53 |
| Chipaca | jam: WRT dispatch not being a symlink to the charm (a feature we want IMHO), I'm afraid we need to drop the "don't look at the env" thing. This is probably fine... as long as we unset JUJU_DISPATCH_PATH | 10:00 |
| Chipaca | otherwise loopy fun could happen | 10:00 |
| Chipaca | (we try to detect and stop said fun, but ¯\_(ツ)_/¯) | 10:01 |
| jam | ah, because if dispatch isn't a symlink, then we don't know who the target of the link is? | 10:01 |
| jam | Chipaca, we'll have to be careful to not invoke every event 2x then | 10:01 |
| jam | eg, 'install => ../src/charm.py; dispatch: shell that invokes ./src/charm.py' that would default to firing install 2x | 10:02 |
| Chipaca | jam: hence dropping the env key | 10:02 |
| jam | Chipaca, I think we need dispatch to not just be a symlink because of the "how do you apt install things so that your python code can cleanly import them" | 10:02 |
| Chipaca | jam: yep | 10:02 |
| jam | Chipaca, even dropping the env var, we still trigger it 2x. | 10:02 |
| jam | we just don't trigger it in an infinite loop :) | 10:02 |
| jam | (doing it in dispatch also handles the "my pod got rescheduled so I need to do it again" case) | 10:03 |
| Chipaca | yep | 10:03 |
| Chipaca | jam: so main would need to check for, and ignore, hooks that get triggered via hooks/ when it's also going to be called a-la-dispatch | 10:04 |
| Chipaca | this might involve further env tweaks | 10:04 |
| * Chipaca needs a whiteboard | 10:05 | |
| jam | Chipaca, *setting* an env var to indicate we are running might be a better awy | 10:05 |
| jam | way | 10:05 |
| jam | we trigger but then in main we see "JUJU_DISPATCH_ALREADY_RUNNING_DONT_DO_ANY_MORE" | 10:06 |
| jam | and then exit cleanly | 10:06 |
| Chipaca | OPERATOR_DISPATCH_IN_PROGRESS_PLEASE_STAND_BY | 10:10 |
| Chipaca | PLEASE_ABSTAIN_FROM_COMING_FROM_DISPATCH | 10:11 |
| * Chipaca forgets how INTERCAL works | 10:11 | |
| jam | Chipaca, the compiler language with no pronounceable acronym, abbreviated INTERCAL | 10:15 |
| jam | nice | 10:15 |
| jam | Chipaca, if the word PLEASE does not appear often enough, the program is rejected as impolite, if too often, it is rejected for excessive politeness | 10:17 |
| Chipaca | jam: having to find the right balance between rude and obsequious was part of the fun | 10:17 |
| jam | Chipaca, can't you just have an array of PLEASE at the end and then trim/append as necessary ? | 10:18 |
| Chipaca | what even is an array | 10:19 |
| mup_ | PR operator#259 opened: Relation created event <Created by jameinel> <https://github.com/canonical/operator/pull/259> | 10:22 |
| jam | https://github.com/canonical/operator/pull/259 expands on Dmitrii-Sh's work to provide Harness support for relation-created. | 10:23 |
| mup_ | PR #259: Relation created event <Created by jameinel> <https://github.com/canonical/operator/pull/259> | 10:23 |
| jam | Chipaca, we'll just meet in the charm docs hangout | 10:25 |
| * Chipaca afk (lunch) | 11:10 | |
| facubatista | Muy buenos días a todos! | 11:21 |
| jam | morning facubatista | 11:30 |
| jam | Chipaca, when you're back around, I've been trying to play with your documentation branch, and so far I haven't found a way to link to another function in a docstring | 11:30 |
| jam | Online I see things like: https://cheat.readthedocs.io/en/latest/rst.html | 11:31 |
| jam | that say you should use ":py:meth:`ops.testing.Harness.method`_" | 11:31 |
| jam | and doing so doesn't generate an error, but in the generated HTML it just puts the raw string above (which looks bad) | 11:31 |
| jam | and the link it generates doesn't seem to go anywhere. | 11:31 |
| facubatista | hola jam | 11:32 |
| facubatista | jam, did you try with a real name? (not "method") | 11:33 |
| facubatista | jam, also note there's no underscore at the end in the docs | 11:34 |
| jam | facubatista, yeah, it was real names. It was the underscore that was a problem. | 11:36 |
| jam | Which, I'd rather have `enable_hooks`_ work than :py:meth:`ops.testing.Harness.enable_hooks` | 11:36 |
| jam | but at least the latter actually creates a link | 11:36 |
| jam | actually, you likely want: | 11:36 |
| jam | :py:meth:`~ops.testing.Harness.enable_hooks` | 11:37 |
| jam | which then at least renders the HTML as 'enable_hooks()' | 11:37 |
| jam | thanks for the catch | 11:37 |
| facubatista | np | 11:38 |
| facubatista | I guess they don't use just `enable_hooks` because that name may be in different places | 11:39 |
| facubatista | I don't see what the :meth:/etc are for, maybe they are rendered differently? or there is the possibility of rendering them differently? | 11:40 |
| jam | facubatista, so why you need :py:meth: in the first place? | 11:40 |
| jam | interesting, :py:meth: also supports :py:meth:`.foo` which is quite a bit better | 11:41 |
| jam | but yeah, I'm not sure why you would need to say "I'm refering to the function, not the class" when it should be inferred by what the target is | 11:42 |
| facubatista | jam, the problem is that ops.foo.bar may be ops(pkg).foo(mod).bar(func) or ops(mod).foo(class).bar(meth) | 11:44 |
| facubatista | jam, note that you may have documentation from previous project versions which doesn't really reflect "current reality", so trying to match "real code" is not an option | 11:45 |
| facubatista | mmm... I guess old docs will be together will old code in a release branch... | 11:46 |
| facubatista | I don't know | 11:46 |
| jam | yeah. I was thinking that theoretically it could be either, but functionally you are explicitly linking to the one that can be imported. | 11:46 |
| jam | Anyway :py: doesn't do what we want | 11:46 |
| jam | but :py:meth:`.enable_hooks` does | 11:47 |
| jam | facubatista, Chipaca : it seems the docstring of __init__ is just completely ignored. So you have to put the doc string for those arguments on the Class itself. | 11:55 |
| jam | also, sphinx doesn't seem to do anything with the Type annotations (AFAICT) | 11:56 |
| jam | vs if you use the (charm.CharmBase) | 11:59 |
| jam | if you use: | 11:59 |
| jam | Args: | 11:59 |
| jam | foo (charm.CharmBase): this is a foo | 11:59 |
| jam | it will give you a link to charm.CharmBase in the docs | 11:59 |
| jam | and it doesn't do it for | 12:00 |
| jam | Args: | 12:00 |
| jam | foo: charm.CharmBase | 12:00 |
| jam | so it is special syntax around () | 12:00 |
| jam | hm. oddly it does do Return type: Mapping from type annotations | 12:01 |
| jam | and for simple types it does inject (int) from type annotations | 12:01 |
| jam | It is just the complex Optional[blah, blah] that it doesn't seem to know what to do with. | 12:01 |
| Chipaca | sorry i'm late | 12:04 |
| Chipaca | bug revue time! :) | 12:04 |
| facubatista | oh | 12:04 |
| Chipaca | jam: hm, maybe i'm missing some tweaks or sth | 12:05 |
| Chipaca | to the config i mean | 12:05 |
| Chipaca | jam: afterwards, point me at where you see this | 12:05 |
| facubatista | jam, we moved the bug review to tomorrow | 12:49 |
| facubatista | Chipaca, jam, and the charmhub x-team for today was cancelled | 12:50 |
| Chipaca | yep | 12:50 |
| * facubatista brb | 12:50 | |
| Chipaca | facubatista: but not the charmhub dev weekly | 12:50 |
| facubatista | Chipaca, you refer to "Weekly Operator Framework Sync"? | 13:06 |
| jam | Chipaca, is that the Kafka one ? | 13:11 |
| Chipaca | facubatista, jam, no this is charm store (for us, the charmcraft store flow) | 13:13 |
| jam | ah gotcha | 13:14 |
| jam | Chipaca, it is also possible that the fancy type annotations stuff is off because it is __init__ | 13:15 |
| facubatista | Chipaca, sorry, I don't know which one you refer to as "charmhub dev weekly" | 13:15 |
| jam | it seems that Sphinx ignores the docstring of __init__ and only uses the docstring on the class | 13:15 |
| Chipaca | jam: i've merged your testing pr in and am poking at it | 13:15 |
| Chipaca | facubatista: ¯\_(ツ)_/¯ dunno why you're asking me so much about my calendar :-D | 13:15 |
| Chipaca | jam: __init__ is part of it | 13:15 |
| facubatista | jam, that's a good thing IMO, __init__ shouldn't have docstrings (as any special methods) | 13:16 |
| Chipaca | jam: it seems ivar also trips it up | 13:16 |
| jam | interesting. I had an ivar though I've removed it in the latest harness-hinting | 13:16 |
| jam | and moved things to class docstring | 13:16 |
| facubatista | Chipaca, the moment you told me that the charmhub dev weekly was not cancelled, I thought I was involved | 13:17 |
| Chipaca | facubatista: you will be at some point! | 13:17 |
| Chipaca | facubatista: just not yet | 13:17 |
| jam | Chipaca, https://youtu.be/tUoBkhTFdWA?t=6 | 13:18 |
| Chipaca | jam: https://youtu.be/RySHDUU2juM?t=6 | 13:19 |
| jam | yeah :) | 13:19 |
| Chipaca | (actually wanted the seagulls one but, eh) | 13:20 |
| jam | https://youtu.be/U9t-slLl30E | 13:20 |
| Chipaca | jam: so, dropping the ivar, and setting autoclass_content = 'both' in conf.py, i think DWYW | 13:21 |
| Chipaca | jam: if you give that a try, i can add the change to conf.py in my pr if it works | 13:23 |
| Chipaca | jam: wrt documenting the ivar, using #: comments might be the way to go | 13:24 |
| jam | that particular ivar was irrelevant as it turned into a @property anyway | 13:24 |
| Chipaca | jam: and properties have a doc of the getter :) | 13:25 |
| jam | yep | 13:25 |
| Chipaca | jam: I might look into having a big fat warning message for undocumented things :-D | 13:25 |
| * Chipaca is sure somebody's written that already | 13:25 | |
| jam | Chipaca, doesn't pydocstyle do that? | 13:26 |
| Chipaca | jam: i think so yes | 13:27 |
| Chipaca | jam: but that doesn't make it easy to spot unless you go look at its output | 13:27 |
| Chipaca | whereas having it shout at you in the docs themselves could be the right kinda stick | 13:27 |
| Chipaca | jam: i'm only half serious fwiw | 13:27 |
| jam | Chipaca, autoclass_content = 'both' seems to do what I was expecting for the class docstring | 13:29 |
| jam | it drops the nice name of "OptionalYAML" in favor of Union[str, TextIO, None] which isn't great from a 'communicate to the user' perspective, but at least it renders something > nothing | 13:30 |
| facubatista | Chipaca, jam, standup? | 13:31 |
| jam | Chipaca, did we lose you? | 13:33 |
| karimsye | is there a preferred way of keeping/maintaining the podSpec in a charm. should I use a podSpec YAML file that gets loaded and populated based on charm config or should the charm create a podSpec dictionary from scratch based on config options? | 15:23 |
| jam | karimsye, most charms that we've seen so far do more of a dict that fills in aspects from config/relation-get etc. | 15:24 |
| jam | otherwise you are applying a template in order to load it from yaml, to do essentially the same thing. | 15:25 |
| jam | that said, people have said that they'd prefer to render a yaml template and load it to pass it in. likely because the examples they are cribbing from were yaml to start with | 15:25 |
| karimsye | jam: thanks, I like the YAML template file as well | 15:45 |
| * Chipaca EODs | 17:49 | |
| * facubatista vanishes away | 22:06 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!