[04:55] <MarkMaglana> Hi. Sharing my early attempts at using the test harness for feedback. I <3 how it simplifies my unit test drastically! https://github.com/relaxdiego/charm-k8s-grafana/commit/38fa63ad8918d0a178986ccc2032d89994029392
[04:55] <MarkMaglana> (Ignore the FrameworkAdapter for now. I'm seeing the light and may soon have no need for it)
[05:41] <MarkMaglana> Question: What is the recommended way to get the model name? I've been using `os.environ["JUJU_MODEL_NAME"]` in my code but I suspect that's not the smartest way.
[06:40] <jam> morning all
[06:41] <jam> MarkMaglana, good to hear you're finding Harness good to use.
[06:41] <jam> MarkMaglana, I don't think we currently expose JUJU_MODEL_NAME from the framework. something like self.model.name sounds like the place to put it
[06:41] <jam> can you file a github issue?
[06:42] <jam> MarkMaglana, along with your use case as to what you need the model name for
[06:42] <jam> (generally charms shouldn't care, but I think for K8s you need it to configure pod names)
[07:08] <MarkMaglana> @jam thanks for the reply! yes you got it right, it's for getting the underlying k8s pod's status so i can report its liveness/readiness back to Juju via OF.
[07:10] <MarkMaglana> i'll go ahead and file that github issue
[07:21] <MarkMaglana> 13:41:26 <jam> MarkMaglana, good to hear you're finding Harness good to use. <--- As a friend used to say "the best code is the one I don't have to write!" and I adhere to that where feasible. :-)
[08:04] <jam> morning Chipaca
[08:04]  * Chipaca is being phone support rn
[08:07] <Chipaca> now yes
[08:07] <Chipaca> jam: morning! :-)
[08:11] <jam> Chipaca, how's the new/old laptop treating you? did they fix the issue?
[08:11] <Chipaca> jam: I haven't been able to get the hard drive back into it yet, they tightened the screws past what my screwdriver could do (have ordered a new one)
[08:12] <Chipaca> my T5 head died to bring me this information
[08:12] <jam> Chipaca, wow, a whole new laptop just for a couple screws :)
[08:12] <jam> (ah the joy of english ambiguity)
[08:12] <Chipaca> :)
[08:12] <Chipaca> i probably could've phrased it better (but why would i)
[08:13] <jam> you were perfectly understandable, I just enjoy puns
[08:13] <Chipaca> also, that laptop is coming up for its 3rd anniversary, so shold i really call it 'new'
[08:15] <jam> my laptop is now 'bowed' so I'll need to get something new before the next sprint. Whenever we actually meet in person again :)
[08:17] <jam> its also fairly old, so I've been wanting to update it anyway
[08:18] <mup_> Issue operator#274 opened: Currently no way to get the model name <Created by relaxdiego> <https://github.com/canonical/operator/issues/274>
[08:18] <mup_> PR operator#252 closed: ops/testing.py: document Harness in Google style <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/252>
[08:23] <Chipaca> jam: bowed?
[08:24] <Chipaca> makes me think the battery's bulging, but that's probably the wrong meaning
[08:25] <jam> Chipaca, nope, that's exactly what I mean
[08:25] <Chipaca> youch
[08:25] <Chipaca> you removed the battery, yes?
[08:25] <jam> Chipaca, I drained the battery so it isn't powered, but it is a Mac and I don't have the little torx. I need to take it to the shop
[08:26] <Chipaca> ah. little torxes and the little prying pluck needed, right?
[08:26] <Chipaca> jam: my old canonical-bought mac laptop developed that, and the shop here swapped the battery for a new one for 50£ IIRC (pre-corona obvs)
[08:27] <Chipaca> that first my is about possession, not ownership fwiw
[08:27] <jam> yeah, it only really started bowing about 2 weeks ago, and I only use it when traveling so it hasn't been high priority
[08:28] <Chipaca> jam: i'd be freaking out about it catching fire, but that's probably because everything around me is flammable
[08:28] <Chipaca> also inflammable
[08:29] <jam> Chipaca, I've been looking at some of the network-get support. It is straightforward to let people do 'pre-canned' responses, but I'd like to actually design something that is better for testing your stuff
[08:29] <Chipaca> it was the only time i've noticed these houses are basically chimneys filled with kindling
[08:29] <jam> should I start with  the former as I design the latter? or skip it because we don't really want people to have to know the details
[08:30] <jam> and/or we should probably talk through what we think are ideals for how people would interact with networking and charm testing.
[08:30] <Chipaca> jam: the latter sounds more powerful, but the devil is in the details (and schedules)
[08:30] <jam> Chipaca, indeed.
[08:31] <Chipaca> jam: want to timebox some design and see where we get?
[08:31] <jam> sounds reasonable
[08:31] <facubatista> Muy buenos días a todos!
[08:31] <Chipaca> whaaat
[08:31] <Chipaca> facubatista: cucha nene
[08:32] <jam> morning facubatista
[08:32] <facubatista> hola Chipaca, jam :)
[08:33] <Chipaca> jam: on an unrelated note, did you see my bug+patch to sphinx?
[08:34] <jam> Chipaca, link?
[08:34] <jam> btw, https://github.com/canonical/operator/pull/272 needs your eyeballs
[08:34] <mup_> PR #272: ops/charm.py: Update the Docstrings to Google style <Created by jameinel> <https://github.com/canonical/operator/pull/272>
[08:34] <Chipaca> jam: https://github.com/sphinx-doc/sphinx/pull/7655
[08:34] <mup_> PR sphinx-doc/sphinx#7655: Make sphinx.util.typing.stringify render optional unions better <Created by chipaca> <https://github.com/sphinx-doc/sphinx/pull/7655>
[08:36] <jam> Chipaca, ah, so that was doing Optional if you had exactly 1 type and None as the other option?
[08:36] <Chipaca> jam: it was doing Optional[foo], but not Optional[Union[foo, bar]]
[08:37] <Chipaca> ie it was doing Union[foo, None] but not Union[foo, bar, None]
[08:37] <jam> Chipaca, presumably if you did Union[foo, None] it would also translate that to Optional[foo] as well ?
[08:37] <Chipaca> yep
[08:39] <Chipaca> jam: btw, compare https://operator-framework.readthedocs.io/en/latest/#ops.testing.Harness and https://operator-framework.readthedocs.io/en/docs-tri/#ops.testing.Harness
[08:39] <facubatista> Chipaca, #!/bin/bash -> #!/bin/sh ... I always don't know if (why) it's better to use `sh` there
[08:39] <jam> Chipaca, i'm a bit surprised to see all Unions end up with Optional
[08:39] <jam> but if that is all they track, then I guess
[08:39] <Chipaca> facubatista: smaller and faster
[08:40] <Chipaca> jam: yeah i was surprised as well (but the current Optional becomes Union isn't very good either)
[08:40] <jam> 'dash' is the current /bin/sh which is Posix compliant, but not Bash compliant
[08:40] <facubatista> Chipaca, and for anything not "real command line usage", the same than bash?
[08:40] <facubatista> oh:
[08:40] <facubatista> $ ll /bin/sh
[08:40] <facubatista> lrwxrwxrwx 1 root root 4 ago 11  2018 /bin/sh -> dash
[08:41] <facubatista> nice
[08:41] <Chipaca> facubatista: unless you need bash features in your script, then yes
[08:41] <jam> https://wiki.archlinux.org/index.php/Dash claims it is 4x faster than bash and smaller footprint
[08:41] <Chipaca> some things in bash are nice / very convenient
[08:41] <jam> it doesn't have support for things like arithmetic in shell IIRC
[08:41] <jam> I remember when Ubuntu switched and it broke a lot of scripts that assumed /bin/sh was bash
[08:41] <Chipaca> arithmetic yes, that's posix afaik
[08:42] <Chipaca> $ sh -c 'echo $((1+1))'
[08:42] <Chipaca> 2
[08:42] <Chipaca> no $RANDOM though
[08:43] <facubatista> $ python3 -c "print(1+1)"
[08:43] <facubatista> 2
[08:43] <facubatista> :p
[08:43] <Chipaca> no brace expansion
[08:43] <Chipaca> no a..b expansion
[08:43] <facubatista> Chipaca, for the docstring, what about "Must override in each command with its respectively core working code."?
[08:43] <Chipaca> facubatista: what is 'core working code'?
[08:44] <facubatista> Chipaca, *the code* of the command that makes the command do what the command does
[08:45] <facubatista> the rest is just boilerplate to make that code run
[08:45] <jam> apt install devtools comes with 'checkbashisms'
[08:45] <jam> though it is written in perl...
[08:46] <Chipaca> jam: shellcheck will look at the #! line and tell you about them in excruciating detail
[08:47] <jam> https://mywiki.wooledge.org/Bashism
[08:47] <Chipaca> facubatista: how about something more like "this is called to have the command do its work, and should be overridden by the command implementation" or something?
[08:48] <jam> keyword 'function', for loops, extended globs
[08:48] <facubatista> Chipaca, I never know the "tone" of the docstrings when "imperative" doesn't fit
[08:49] <Chipaca> jam: command substitutions also
[08:50] <jam> Chipaca, https://operator-framework.readthedocs.io/en/latest/#ops.testing.Harness doesn't seem to have a link for the types
[08:50] <Chipaca> facubatista: threading.Thread's run method says "Method representing the thread’s activity.\n\nYou may override this method in a subclass. [...]"
[08:50] <jam> with: https://operator-framework.readthedocs.io/en/docs-tri/#ops.testing.Harness I can click to jump to CharmBase
[08:51] <Chipaca> jam: yep, and latest has the types in the signature which gets messy
[08:51] <jam> (and I personally prefer Parameters as a section that doesn't cause the params to indent as far)
[08:51] <facubatista> Chipaca, improving also the docstrings of that whole class
[08:51] <Chipaca> jam: is there anything in docs-tri that's off?
[08:52] <Chipaca> or, is there anything in latest that's better than the one in docs-tri
[08:52] <Chipaca> turns out it was easy to get rtd to use latest sphinx :-)
[08:52] <jam> Chipaca, I do find latest harder to read for advanced type signatures, I find it kind of snazzy for simple ones, eg: https://operator-framework.readthedocs.io/en/latest/#ops.testing.Harness.set_leader
[08:53] <jam> latest looks 'more like the source' but definitely Harness.__init__ gets ugly
[08:53] <Chipaca> yeah, on both points
[08:54] <Chipaca> i can probably put the types back in the signature, and they might be a bit better than latest
[08:55]  * Chipaca tries
[08:57] <jam> Chipaca, I'm used to typed languages, so seeing types in my signatures is expected and comforting. I don't know that others feel that way :)
[08:58] <jam> I think there are pros and cons of either path. I really like being able to go to the link of "what is this type" so you can figure out how you might want to interact with it.
[08:59] <Chipaca> jam: setting the type hints back in the signature does not look any better than on 'latest' with the newer sphinx, meaning add_leader looks good but e.g. update_config already looks scary
[08:59] <jam> does key_values: dict = None give a better result?
[09:00] <jam> and List[str] vs Iterable[str]
[09:00] <Chipaca> jam: also it's not a link in the signature :-/
[09:00]  * Chipaca checks
[09:00] <jam> The goal was to not say "this has to exactly be a list object" but Iterable feels overly abstractd
[09:01] <jam> saying list felt bad when I set it to the empty tuple as the default value :)
[09:01] <jam> (cause if you set it to [] then linters complain that you're setting a default to a mutable value)
[09:02] <facubatista> right, don't use [] as default, ever
[09:02] <Chipaca> saying list and setting it to default to a tuple would also cheese off mypy
[09:02] <facubatista> well, 99.999% ever :p
[09:02]  * Chipaca was already thinking of counter-arguments to "ever"
[09:03] <facubatista> jam, "iterable" is a totally firm thing in Python, sounds good
[09:03] <Chipaca> jam: no it doesn't look particularly better with List/Dict instead of Iterable/Mapping
[09:03] <jam> facubatista, yeah, I do remember doing it in the past, and using it to populate a dict or something, and then suddenly adding a value here was adding it there too
[09:03] <Chipaca> still wraps
[09:03] <facubatista> Chipaca, I used {} once in real code :D
[09:03] <Chipaca> shocking
[09:03] <facubatista> but not as a "default parameter", just a "dict I wanted to have inside the function definition between calls for caching"
[09:04] <Chipaca> so, ok, i'll push the change from docs-tri to a pr once again :)
[09:06] <mup_> PR operator#275 opened: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/275>
[09:08] <jam> Chipaca, you asked for it to be merged into docs-tri
[09:08] <jam> so it doesn't show any diff and says already merged
[09:08] <Chipaca> hah
[09:08] <mup_> PR operator#275 closed: explicitly ask for a newer sphinx on rtd <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/275>
[09:08]  * Chipaca <~ dumb banana
[09:09] <jam> Chipaca, you can change the target branch after proposing it
[09:10] <facubatista> Chipaca, just pushed the charmcraft branch
[09:10] <facubatista> let's see how travis goes
[09:11] <Chipaca> jam: docs-tri on rtd now has the charm changes
[09:12] <Chipaca> if you're wanting to look at that
[09:12] <Chipaca> need to fix that pr now :)
[09:14] <mup_> PR operator#276 opened: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/276>
[09:18] <Chipaca> my new T5 arrived! brb
[09:26] <facubatista> wee, "a man and a screwdriver", the movie
[09:28] <jam> Chipaca, that seems very fast
[09:33] <Chipaca> jam: i'm spoiled, geographically
[09:40] <facubatista> Chipaca, more important: were you able to open the laptop?
[09:46] <Chipaca> facubatista: yes! uefi's all messed up and my bios has more enterprisey features than when it went off but everything seems ok
[09:46] <facubatista> good
[09:50] <facubatista> jam, re #269 ... I understand why calling other_unit.is_leader() is a bad thing, and I think it's better to raise an exception than answering False or None... but if "you should not call is_leader on a different unit", maybe we shouldn't expose it?
[09:50] <mup_> Issue #269: Warn that model.unit.is_leader() can raise an exception <Created by timClicks> <https://github.com/canonical/operator/issues/269>
[09:51] <jam> facubatista, that was my point as well, trying to not have the method vs having it but being a runtime error
[09:51] <jam> but it means having multiple Unit types one representing *you* and one representing all the other units
[09:51] <facubatista> otoh, it looks weird if Unit (as the object) exposes the method *sometimes*
[09:52] <facubatista> jam, thinking out loud, what if we deprecate Unit.is_leader, and we add something `self.is_unit_leader()`?
[09:54] <jam> I don't think this is going to be the only thing that you can do on yourself that you couldn't do on another.
[09:54] <jam> so I'm not opposed to having a different type for the Unit representing you
[09:58] <facubatista> OTOH, I feel better to do `wrong_unit.is_leader()` and getting SomeError("You're calling is_leader on a different Unit that yours, which doesn't make sense") than a silly AttributeError
[10:01] <facubatista> So, current solution is the best (TM)
[10:01] <facubatista> (maybe we could improve the exception message)
[10:02] <facubatista> jam, this is all yours: https://github.com/canonical/charmcraft/pull/1
[10:02] <mup_> PR charmcraft#1: Draft to show several characteristics <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/1>
[10:02] <jam> facubatista, yeah, I think it is a fair trade for where we are at. AttributeError hints at a programmer error as well to me (and your editor won't try to fill it in for you)
[10:04] <facubatista> jam, but AttributeError is obscure, when you have that method in "other" units... like, using it, getting the error, reading it and thinking "mmm... the Unit has not is_leader method???", going to the code, *seeing it*, seeing other code that uses it just fine, etc
[10:05] <facubatista> getting SomeError(VERY_GOOD_EXPLANATION) would totally help
[10:05] <jam> yeah, that is what we've been using RuntimeError for, figuring out language that people understand for that is probably the point
[10:07] <facubatista> jam, I'd improve the message... "cannot determine leadership status for remote applications" looks like "the process wasn't able to do that at that time"
[10:08] <jam> invalid request: leadership status of remote units is not available
[10:08] <jam> invalid request: you can't do that dave
[10:08] <jam> is_leader is only valid for yourself
[10:09] <facubatista> "is not available" <-- again, looks like messaging failed or network glitch
[10:09] <facubatista> I'd totally go with "you can't do that dave"
[10:11] <facubatista> and we can have a counter, if you call that more than three times, the exception message turns into Daisy Bell lyrics
[10:12] <jam> leadership status of remote units is not visible to other applications
[10:12] <jam> leadership status is only visible for your own application
[10:14] <__chip__> eeee
[10:15] <__chip__> eeeₑₑₑ
[10:15] <__chip__> ₔₔₔəəə
[10:16] <__chip__> convincing my laptop that I _didn't_ have windows, nor did i want to 'repair' it for the lack, was harder than i expected
[10:17] <__chip__> now i need to sync my work back and I'll be set :-D
[10:18] <Chipaca> anyway, time for a break
[10:18] <Chipaca> __chip__: can i get you a coffee?
[10:18] <__chip__> Chipaca: please
[10:18] <jam> Chipaca, I'll go make one now, come by anytime to pick it up
[10:19] <__chip__> jam: 👍
[10:23] <facubatista> Chipaca, jam, is the "charm docs daily" currently a thing?
[10:24] <jam> facubatista, it has not been happening but we've been stopping by to check each day
[10:24] <facubatista> jam, "polling"
[10:24] <__chip__> facubatista: "it's complicated"
[10:25]  * facubatista is complicated
[10:33] <MarkMaglana> jam and and __chip__ aren't really in the same house/neighborhood are they?
[10:33] <jam> MarkMaglana, __chip__ is Chipaca's other machine
[10:33] <jam> and no, we're continents apart
[10:34] <jam> hence why I can offer to make as many coffees as I want
[10:34] <jam> :)
[10:34] <MarkMaglana> lol OK. then can I have a cup as well, pretty please?
[10:35] <__chip__> jam: just one
[10:35] <__chip__> continent i mean
[10:35] <jam> MarkMaglana, happy to
[10:36] <jam> I'm going to have a hard time sleeping with all these extra coffees lying around
[10:36] <jam> Can't let them go to waste
[10:38] <MarkMaglana> might as well add some cold brew in that mix topped by whole milk foam and some simple syrup.
[10:38] <__chip__> dalgona also
[10:39] <jam> I have not had dalgona before
[10:39] <jam> seems interesting
[10:40] <__chip__> what's up with the failures in travis wrt the test main charm?
[10:41] <__chip__> jam: we'd have it frequently in high school, before it was called that
[10:41] <__chip__> we just called it 'batido'
[10:44] <facubatista> MarkMaglana, each team member is from a different continent :p
[10:44] <jam> facubatista, clearly the next hire should be NZ/Australia so we can maximize our worldwide coverage
[10:45] <facubatista> Antarctica FTW
[10:45] <MarkMaglana> facubatista i'm in one of those southeast asian archipelagoes.
[10:45] <MarkMaglana> archipelagos? archipelagoes? anyway, group of islands.
[10:48] <facubatista> :)
[10:50] <jam> facubatista, but if Antarctica then couldn't they be in *any* TZ ?
[11:00] <jam> facubatista, Chipaca coming along to meet with gnuoy ?
[11:01] <facubatista> yes
[11:15] <MarkMaglana> jam: When you get the chance, can you shed some light on this thing I'm getting blocked at? I was attempting to remove one of the Grafana charm's delegators as well as the FrameworkAdapter and came across an issue. See commit https://github.com/relaxdiego/charm-k8s-grafana/commit/b689a77cb2714075b2c88e5fe6442e26f1ca033e
[11:23] <facubatista> jam, Chipaca, for later: did we consider that saving state in the controller may be expensive? e.g. if the controller is in another DC/cloud
[11:42] <mup_> Issue operator#277 opened: Helper library of common operations <Created by stub42> <https://github.com/canonical/operator/issues/277>
[12:01] <__chip__> jam, facubatista: i'm going to be 5 minutes
[12:01] <facubatista> __chip__, ack, will heat water for the mate, then
[12:46] <jam> Chipaca, __chip__ still need your eyeballs on https://github.com/canonical/operator/pull/272
[12:46] <mup_> PR #272: ops/charm.py: Update the Docstrings to Google style <Created by jameinel> <https://github.com/canonical/operator/pull/272>
[12:50] <mup_> Issue operator#278 opened: Unit.status not unit tested <Created by jameinel> <https://github.com/canonical/operator/issues/278>
[12:55] <facubatista> jam, I'm failing to relate my blog to apache :/ ... I see that one of the items apache2 provides is:
[12:55] <facubatista>   apache-website:
[12:55] <facubatista>     interface: apache-website
[12:55] <facubatista>     scope: container
[12:55] <facubatista> then, my blog requires:
[12:55] <facubatista>   apache:
[12:55] <facubatista>     interface: apache-website
[12:55] <facubatista>     scope: container
[12:56] <facubatista> but then I get
[12:56] <facubatista> $ juju add-relation bdv:apache apache2:apache-website
[12:56] <facubatista> ERROR no relations found
[12:56] <jam> facubatista, do you have "subordinate: true" in your metadata.yaml ?
[12:56] <facubatista> maybe I needed to do something different when deploying?
[12:56] <facubatista> oh
[12:57] <jam> (I hadn't told you about it because I had forgotten it, but as I'm writing docs I came across it again)
[12:57] <facubatista> jam, no problem that you didn't tell me, I'm a little frustrated about not finding this myself in the docs
[12:59] <facubatista> ok, upgrade no longer works because I changed the application's subordinacy, let's remove and redeploy
[13:02] <facubatista> ah, and then the `juju deploy` sits there in 'waiting' until I relate it to the other app
[13:03] <facubatista> it could totally say that in the message
[13:05] <__chip__> jam: 272 gtg
[13:09] <jam> \o/
[13:10] <mup__> PR operator#272 closed: ops/charm.py: Update the Docstrings to Google style <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/272>
=== mup__ is now known as mup_
[13:28] <jam> facubatista, Chipaca does typing have a type like Optional but meaning "you *can* set this, but you really shouldn't"? :)
[13:29] <facubatista> jam, I've been checking its docs, after you used it... it looks is an explicit way that you can use that, or the default... IOW:
[13:29] <facubatista> if you do    def foobar(foo: Optional(int) = None):
[13:29] <facubatista> foo is optional, yes, as it has a default
[13:30] <facubatista> but the Optional would mean that you can actually pass an int, and you can even pass None!
[13:30] <facubatista> without the optional, at typing level, you could pass an int or nothing
[13:30] <facubatista> that is what I understood from reading a little the docs, never really tried it
[13:31] <jam> facubatista, standup?
[13:32] <mup_> PR operator#279 opened: ops/model.py: Document public methods and types <Created by jameinel> <https://github.com/canonical/operator/pull/279>
[14:14] <jam> Chipaca, pip3 install --upgrade --user flake8 made it fail for me, but because there is a new pycodestyle which "has no attribute 'break_around_binary_operator'"
[14:15] <jam> pip3 freeze our deps :)
[14:18] <jam> ugh, it seems flake8 had a long standing pycodestyle <2.4.0 but tip of flake8 says 2.6.0 but doesn't actually work with it?
[14:22] <jam> so test suite passes if I do: pip3 install --upgrade --user flake8==3.7.* autopep8 pycodestyle==2.5.* mccabe pyflakes==2.1.*
[14:22] <jam> it fails to run with flake8==3.8.* which needs pycodestyle 2.6.0 but doesn't actually work with it AFAICT
[14:23] <jam> (in neither case does it cause E402 errors, which is what we see on Travis)
[14:39] <__chip__> newsflash: ops doesn't work with python 2
[14:40]  * __chip__ glares at his new venv
[14:42] <__chip__> jam: was the problem with the doc of RelationData that things like :class:Application weren't getting rendered correctly?
[15:28] <__chip__> jam: what category in the discourse shold the readme point to?
[15:28] <__chip__> /c/charming?
[15:28] <__chip__> i'm also going to point at /c/docs/operator-framework
[15:28] <jam> __chip__, the issue is that RelationData's docstring was completely absent
[15:28] <jam> I was trying to figure out if :class:Application worked or if you need :class:`ApplicationData`
[15:29] <__chip__> jam: i'm not seeing that, fwiw, with either version of sphinx here
[15:29] <jam> but it didn't render anything or complain
[15:29] <__chip__> jam: without the `s it doesn't render it as a link (so it outputs the string verbatim)
[15:29] <__chip__> including the :class:
[15:29] <__chip__> jam: but again, that's here where it is rendering :)
[15:30] <__chip__> strange that there it isn't
[15:30] <__chip__> i built a new env to see if i had anything left over that would be doing it, and no
[15:30] <__chip__> and i tried with both sphines in a new env each time, also no
[15:30] <jam> __chip__, https://imgur.com/U4WQcvp
[15:30] <__chip__> no == it did render, i mean
[15:31] <__chip__> jam: that looks like you're not picking up the :members:
[15:31] <__chip__> jam: ie the defaults from docs/conf.py
[15:33] <jam> __chip__, so it is because I was looking at context.html which was renamed to index.html, but index.html isn't getting the right theme (from what I can tell), so I thought it was the wrong dok
[15:33] <jam> doc
[15:34] <jam> __chip__, wiping out the dir and recreating it revealed the wrong html file
[15:34] <__chip__> jam: the default theme will be different in the local build, it'll be a very spartan thing now rather than the green friendly one
[15:34] <jam> right, that's what I'm seeing, but at least I'm seeing the fields I added :)
[15:34] <__chip__> I could explicitly say 'use the tbd theme' but that's an extra requirement
[15:34] <__chip__> rtd*
[15:35] <__chip__> the rtd theme is bigger than sphinx :-D
[15:36] <__chip__> jam: did you see my question about the discourse?
[15:37] <__chip__> (while i have you here :)
[15:38] <jam> __chip__, So your request for ``{name: stuff}`` means that links don't work. eg: {relation_name: [ :class:`Relation` ]}
[15:38] <jam> for discourse...
[15:38] <__chip__> jam: ah. ufa.
[15:38] <jam> I think timclicks wants us to use https://discourse.juju.is/c/charming
[15:39] <jam> __chip__, ufa ?
[15:39] <__chip__> jam: "rats"
[15:40] <__chip__> as an interjection i mean
[15:40] <jam> __chip__, I'm happy for whatever rendering we like for it. I don't have to have links, but I do kind of like the cross reference
[15:40] <__chip__> me too
[15:40] <__chip__> indeed i like it a little more than i want code to look like code, in small snippets at least
[15:41] <jam> It seems to help the "what is this thing, oh that's what it is, what can I do with it" in a nice way
[15:41]  * __chip__ nods
[15:41] <jam> I can say "map of foo => :class:`Bar`" if you don't want it to look so much like code
[15:42] <jam> It is a pattern I use a lot because we have a lot of maps in our structs
[15:42] <jam> classes even
[15:42] <__chip__> maybe working into a sentence is better
[15:43] <__chip__> as in "a map of foo to :class:`Bar`" or sth
[15:43] <__chip__> dunno
[15:44] <__chip__> jam: i can confirm that setting html_theme to 'sphinx_rtd_theme' renders things almost exactly like on rtd
[15:45] <jam> __chip__, I'll try out the sentence structure.
[15:45] <jam> I think the big thing was realizing that index was, indeed, the correct rendering, and not a mistake
[15:45] <jam> I can live with it
[15:46] <__chip__> ok
[15:46] <__chip__> i can add it to docs/requirements and make it explicit, should help us when we start tweaking the theme
[15:48] <__chip__> pushed that
[15:49] <__chip__> facubatista: dev-requirements.txt, or requirements-dev.txt? i know we had this discussion before but don't remember the outcome
[15:49] <facubatista> __chip__, I prefer requirements-dev.txt, as you locate it more easily when listing the directory
[15:49] <jam> __chip__, do you know why https://github.com/canonical/operator/pull/276/files looks like it is r
[15:49] <mup_> PR #276: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/276>
[15:49] <jam> bringing in my charm.py changes?
[15:50] <facubatista> __chip__, btw, are you working on that? I am
[15:50] <__chip__> jam: i don't, i probably need to rebase or something
[15:50] <__chip__> jam: i'll clean it up before my eod
[15:50] <jam> __chip__, I also prefer requirements-dev because of sorting
[15:50] <__chip__> facubatista: i am not, but i'm updating the README that assumes it's done :-D
[15:51] <__chip__> jam: facubatista: fffantastic
[15:51] <facubatista> __chip__, ack
[15:56] <__chip__> jam: it seems happier now (all i did was rebase to master)
[15:56] <mup_> PR operator#280 opened: Included the dependencies in requirements files, updated README and .travis <Created by facundobatista> <https://github.com/canonical/operator/pull/280>
[15:56] <facubatista> __chip__, ^
[15:56] <jam> __chip__, my guess is that the land-with-squashing is causing one of your patches to look like an additional change
[15:56] <__chip__> facubatista: wouldn't it be enough to say ==5.3.*?
[15:57] <facubatista> __chip__, I don't know, are you sure they use 100% semver?
[15:59] <__chip__> facubatista: I am 3.75% sure about absolutely everything
[15:59] <__chip__> but it adds up in weird ways
[16:00] <facubatista> __chip__, +/- ?
[16:00] <__chip__> 5
[16:00] <facubatista> :)
[16:23] <karimsye> did you guys read this - https://discourse.juju.is/t/experimental-new-feature-k8s-charms-as-operators/2849
[16:24] <karimsye> does it support/conflict with anything you guys have planned?
[16:29] <karimsye> I am guessing I can still use the operator framework to do things like read models,units,applications states and their config
[16:31] <facubatista> karimsye, thanks, will read
[16:31] <__chip__> karimsye: it neither supports nor conflicts with what we have planned so far, and we don't currently have concrete plans to really support that feature
[16:31] <karimsye> facubatista: thanks
[16:32] <__chip__> karimsye: but we do have a blanket 'make things better' for juju on k8s, which might include this (or other work) as juju changes
[16:49] <__chip__> facubatista: i think i saw you say something about having a signature like foo(n: Optional[int] = None)
[16:51] <__chip__> facubatista: if i understood you correctly, you were further saying that   foo(n: int = None)  was OK as well?
[16:51] <facubatista> __chip__, today, 10:29.ar
[16:52] <__chip__> facubatista: yeah, i'm asking if that second part was what you meant to say
[16:52] <facubatista> IIUC, foo(n: int = None) means that if you pass a parameter, it must be an int (you may not pass it)
[16:52] <__chip__> foo(n: int = None)  is wrong
[16:52] <__chip__> because n = None can't be done if n is int
[16:53] <facubatista> according to whom?
[16:53] <__chip__> hmm
[16:53] <__chip__> hold on maybe i misunderstood
[16:54] <__chip__> i was sure i had run this past mypy and it had complained
[16:54] <__chip__> gasp
[16:54] <__chip__> mypy is now saying that Optional happens automatically
[16:55] <__chip__> look:
[16:55] <__chip__> given def foo(n: int = None) -> int:
[16:55] <facubatista> __chip__, https://paste.ubuntu.com/p/pJHQGvttyy/ ?
[16:55] <__chip__>     return 2*n
[16:55]  * __chip__ looks
[16:55] <__chip__> tal cual
[16:55] <__chip__> but now change it to → int and return 2*n
[16:56] <__chip__> it looks like this only works with None, you can't do shenanigans like foo(n: int = 'hello')
[16:57] <__chip__> but for =None, it automatically makes it Optional
[16:57] <__chip__> that's Neat
[16:57] <__chip__> this is new, or when i tested i bungled the test :)
[16:57] <facubatista> __chip__, the problem is the value in multiplication, not the signature
[16:57] <__chip__> facubatista: yes but that's where you see that it's promoted the n to Optional
[16:57] <__chip__> it says the operand is of type "Optional[int]"
[16:57] <facubatista> __chip__, this is fine: https://paste.ubuntu.com/p/vtcgXWNhG7/
[16:58] <__chip__> yep
[16:58] <__chip__> so maybe we can do without those Optionals in our annotations
[16:58] <__chip__> i'll give it a pass over later
[16:58] <__chip__> right now i need to soft-eod and go for a short run and make dinner
[17:00] <facubatista> __chip__, it looks Optional is now optional :p
[17:00] <facubatista> __chip__, see https://paste.ubuntu.com/p/8bmYJSxY79/
[17:00] <__chip__> facubatista: or is it that optional is Optional
[17:00] <facubatista> as it's "optional at Python level", it just does the right thing (tm)
[17:01] <__chip__> facubatista: but, again, only if None afaict
[17:01] <facubatista> __chip__, see `bar` in my last pastebin
[17:02] <__chip__> facubatista: and def foo(n: typing.Union[str, int] = None) -> int: return 2*n    and you see that it's promoting the Union to Optional, and then the stringify of that optional union has the same issue as it does in sphinx
[17:02] <__chip__> facubatista: there's no promotion there
[17:03] <__chip__> typing.Optional just means "it can also be None"
[17:03] <__chip__> because typing.Optional[SomeType] is just typing.Union[SomeType, NoneType]
[17:03] <facubatista> __chip__, I don't care about that special case, as everything else seems to work just fine without using Optional
[17:04] <__chip__> k
[17:04] <facubatista> __chip__, I mean
[17:04] <__chip__> anyway, soft-eod for me
[17:04] <facubatista> __chip__, it looks everything "is just fine" without using Optional at all
[17:04] <__chip__> afaict yes
[17:04] <__chip__> i'm going to try (later) and see what breaks if anything :)
[17:10] <__chip__> oh rats, https://github.com/sphinx-doc/sphinx/pull/7298
[17:10] <mup_> PR sphinx-doc/sphinx#7298: py domain: Add py:property directive to describe a property (refs: #7068) <domains:py> <enhancement> <refactoring> <Created by tk0miya> <https://github.com/sphinx-doc/sphinx/pull/7298>
[17:10] <__chip__> we're going to get into trouble with descriptors
[17:10] <__chip__> with both mypy and sphinx
[17:10] <__chip__> afaict
[17:10] <__chip__> booo
[17:10] <__chip__> ANYWAY I WAS SUPPOSED TO BE GONE
[17:23]  * facubatista bb~1h
[17:29]  * facubatista didn't go :p
[17:51]  * facubatista bb~1h for real now
[19:12]  * facubatista is back
=== mup__ is now known as mup_
[21:04] <__chip__> ok, i'm out
[21:04] <__chip__> facubatista: amañá!
[21:04] <facubatista> __chip__, chaus
[21:21] <__chip__> facubatista: i lied!
[21:21] <__chip__> muahahaha
[21:21] <facubatista> jajaja
[21:21] <__chip__> facubatista: could you review #281?
[21:21] <mup_> PR #281: make flake8 happy again <Created by chipaca> <https://github.com/canonical/operator/pull/281>
[21:22] <mup_> PR operator#281 opened: make flake8 happy again <Created by chipaca> <https://github.com/canonical/operator/pull/281>
[21:22] <__chip__> facubatista: both you and jаm have (i think?) written the same thing but mixed up with other stuff
[21:23] <facubatista> __chip__, indeed; there +1'ed it
[21:23] <__chip__> facubatista: thank you for buying the conflict :-)
[21:24]  * __chip__ pokes travis
[21:26] <facubatista> :)
[21:26] <mup_> PR operator#281 closed: make flake8 happy again <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/281>
[21:30] <__chip__> facubatista: anything i can review for you?
[21:30] <facubatista> __chip__, I lost track, tomorrow need to do a pass on everything
[21:31] <facubatista> I think I have feedback on everything, though
[21:31] <__chip__> facubatista: ok
[21:31] <__chip__> facubatista: you've also been here since forever
[21:31] <__chip__> almost as long as me (but i went off and had dinner and watched some netflix)
[21:31] <facubatista> __chip__, I took a nap :)
[21:31] <__chip__> facubatista: ah, good :)
[21:31]  * facubatista is not 25 since a long time ago
[21:49] <__chip__> facubatista: i can resolve that conflict for you if you want
[21:49] <__chip__> s/if you want/if you don't mind/
[22:03] <facubatista> __chip__, no worries, I will work it out tomorrow
[22:06] <__chip__> grrr, squash merge i hate you so much
[22:06] <__chip__> "i've seen this change before, let me just search for the commit hash"
[22:06] <__chip__> hahaha nope
[22:08] <facubatista> __chip__, we can stop squashing
[22:08]  * facubatista hates squashing, it's human solution to a technical problem
[22:09]  * __chip__ likes butternut squash
[22:18]  * __chip__ zzzs