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) | 04:55 |
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. | 05:41 |
jam | morning all | 06:40 |
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:41 |
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) | 06:42 |
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:08 |
MarkMaglana | i'll go ahead and file that github issue | 07:10 |
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. :-) | 07:21 |
jam | morning Chipaca | 08:04 |
* Chipaca is being phone support rn | 08:04 | |
Chipaca | now yes | 08:07 |
Chipaca | jam: morning! :-) | 08:07 |
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:11 |
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:12 |
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:13 |
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:15 |
jam | its also fairly old, so I've been wanting to update it anyway | 08:17 |
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:18 |
Chipaca | jam: bowed? | 08:23 |
Chipaca | makes me think the battery's bulging, but that's probably the wrong meaning | 08:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
jam | morning facubatista | 08:32 |
facubatista | hola Chipaca, jam :) | 08:32 |
Chipaca | jam: on an unrelated note, did you see my bug+patch to sphinx? | 08:33 |
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:34 |
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:36 |
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:37 |
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:39 |
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:40 |
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:41 |
Chipaca | $ sh -c 'echo $((1+1))' | 08:42 |
Chipaca | 2 | 08:42 |
Chipaca | no $RANDOM though | 08:42 |
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:43 |
facubatista | Chipaca, *the code* of the command that makes the command do what the command does | 08:44 |
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:45 |
Chipaca | jam: shellcheck will look at the #! line and tell you about them in excruciating detail | 08:46 |
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:47 |
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:48 |
Chipaca | jam: command substitutions also | 08:49 |
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:50 |
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:51 |
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:52 |
jam | latest looks 'more like the source' but definitely Harness.__init__ gets ugly | 08:53 |
Chipaca | yeah, on both points | 08:53 |
Chipaca | i can probably put the types back in the signature, and they might be a bit better than latest | 08:54 |
* Chipaca tries | 08:55 | |
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:57 |
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:58 |
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? | 08:59 |
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:00 |
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:01 |
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:02 | |
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:03 |
Chipaca | so, ok, i'll push the change from docs-tri to a pr once again :) | 09:04 |
mup_ | PR operator#275 opened: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/275> | 09:06 |
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:08 | |
jam | Chipaca, you can change the target branch after proposing it | 09:09 |
facubatista | Chipaca, just pushed the charmcraft branch | 09:10 |
facubatista | let's see how travis goes | 09:10 |
Chipaca | jam: docs-tri on rtd now has the charm changes | 09:11 |
Chipaca | if you're wanting to look at that | 09:12 |
Chipaca | need to fix that pr now :) | 09:12 |
mup_ | PR operator#276 opened: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/276> | 09:14 |
Chipaca | my new T5 arrived! brb | 09:18 |
facubatista | wee, "a man and a screwdriver", the movie | 09:26 |
jam | Chipaca, that seems very fast | 09:28 |
Chipaca | jam: i'm spoiled, geographically | 09:33 |
facubatista | Chipaca, more important: were you able to open the laptop? | 09:40 |
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:46 |
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:50 |
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:51 |
facubatista | jam, thinking out loud, what if we deprecate Unit.is_leader, and we add something `self.is_unit_leader()`? | 09:52 |
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:54 |
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 | 09:58 |
facubatista | So, current solution is the best (TM) | 10:01 |
facubatista | (maybe we could improve the exception message) | 10:01 |
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:02 |
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:04 |
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:05 |
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:07 |
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:08 |
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:09 |
facubatista | and we can have a counter, if you call that more than three times, the exception message turns into Daisy Bell lyrics | 10:11 |
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:12 |
__chip__ | eeee | 10:14 |
__chip__ | eeeₑₑₑ | 10:15 |
__chip__ | ₔₔₔəəə | 10:15 |
__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:16 |
__chip__ | now i need to sync my work back and I'll be set :-D | 10:17 |
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:18 |
__chip__ | jam: 👍 | 10:19 |
facubatista | Chipaca, jam, is the "charm docs daily" currently a thing? | 10:23 |
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:24 |
* facubatista is complicated | 10:25 | |
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:33 |
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:34 |
__chip__ | jam: just one | 10:35 |
__chip__ | continent i mean | 10:35 |
jam | MarkMaglana, happy to | 10:35 |
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:36 |
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:38 |
jam | I have not had dalgona before | 10:39 |
jam | seems interesting | 10:39 |
__chip__ | what's up with the failures in travis wrt the test main charm? | 10:40 |
__chip__ | jam: we'd have it frequently in high school, before it was called that | 10:41 |
__chip__ | we just called it 'batido' | 10:41 |
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:44 |
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:45 |
facubatista | :) | 10:48 |
jam | facubatista, but if Antarctica then couldn't they be in *any* TZ ? | 10:50 |
jam | facubatista, Chipaca coming along to meet with gnuoy ? | 11:00 |
facubatista | yes | 11:01 |
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:15 |
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:23 |
mup_ | Issue operator#277 opened: Helper library of common operations <Created by stub42> <https://github.com/canonical/operator/issues/277> | 11:42 |
__chip__ | jam, facubatista: i'm going to be 5 minutes | 12:01 |
facubatista | __chip__, ack, will heat water for the mate, then | 12:01 |
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:46 |
mup_ | Issue operator#278 opened: Unit.status not unit tested <Created by jameinel> <https://github.com/canonical/operator/issues/278> | 12:50 |
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:55 |
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:56 |
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:57 |
facubatista | ok, upgrade no longer works because I changed the application's subordinacy, let's remove and redeploy | 12:59 |
facubatista | ah, and then the `juju deploy` sits there in 'waiting' until I relate it to the other app | 13:02 |
facubatista | it could totally say that in the message | 13:03 |
__chip__ | jam: 272 gtg | 13:05 |
jam | \o/ | 13:09 |
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> | 13:10 |
=== mup__ is now known as mup_ | ||
jam | facubatista, Chipaca does typing have a type like Optional but meaning "you *can* set this, but you really shouldn't"? :) | 13:28 |
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:29 |
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:30 |
jam | facubatista, standup? | 13:31 |
mup_ | PR operator#279 opened: ops/model.py: Document public methods and types <Created by jameinel> <https://github.com/canonical/operator/pull/279> | 13:32 |
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:14 |
jam | pip3 freeze our deps :) | 14:15 |
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:18 |
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:22 |
jam | (in neither case does it cause E402 errors, which is what we see on Travis) | 14:23 |
__chip__ | newsflash: ops doesn't work with python 2 | 14:39 |
* __chip__ glares at his new venv | 14:40 | |
__chip__ | jam: was the problem with the doc of RelationData that things like :class:Application weren't getting rendered correctly? | 14:42 |
__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:28 |
__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:29 |
__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:30 |
__chip__ | jam: that looks like you're not picking up the :members: | 15:31 |
__chip__ | jam: ie the defaults from docs/conf.py | 15:31 |
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:33 |
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:34 |
__chip__ | the rtd theme is bigger than sphinx :-D | 15:35 |
__chip__ | jam: did you see my question about the discourse? | 15:36 |
__chip__ | (while i have you here :) | 15:37 |
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:38 |
jam | __chip__, ufa ? | 15:39 |
__chip__ | jam: "rats" | 15:39 |
__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:40 |
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:41 |
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:42 |
__chip__ | as in "a map of foo to :class:`Bar`" or sth | 15:43 |
__chip__ | dunno | 15:43 |
__chip__ | jam: i can confirm that setting html_theme to 'sphinx_rtd_theme' renders things almost exactly like on rtd | 15:44 |
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:45 |
__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:46 |
__chip__ | pushed that | 15:48 |
__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:49 |
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:50 |
__chip__ | jam: facubatista: fffantastic | 15:51 |
facubatista | __chip__, ack | 15:51 |
__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:56 |
facubatista | __chip__, I don't know, are you sure they use 100% semver? | 15:57 |
__chip__ | facubatista: I am 3.75% sure about absolutely everything | 15:59 |
__chip__ | but it adds up in weird ways | 15:59 |
facubatista | __chip__, +/- ? | 16:00 |
__chip__ | 5 | 16:00 |
facubatista | :) | 16:00 |
karimsye | did you guys read this - https://discourse.juju.is/t/experimental-new-feature-k8s-charms-as-operators/2849 | 16:23 |
karimsye | does it support/conflict with anything you guys have planned? | 16:24 |
karimsye | I am guessing I can still use the operator framework to do things like read models,units,applications states and their config | 16:29 |
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:31 |
__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:32 |
__chip__ | facubatista: i think i saw you say something about having a signature like foo(n: Optional[int] = None) | 16:49 |
__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:51 |
__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:52 |
facubatista | according to whom? | 16:53 |
__chip__ | hmm | 16:53 |
__chip__ | hold on maybe i misunderstood | 16:53 |
__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:54 |
__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:55 |
__chip__ | it looks like this only works with None, you can't do shenanigans like foo(n: int = 'hello') | 16:56 |
__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:57 |
__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 | 16:58 |
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:00 |
__chip__ | facubatista: but, again, only if None afaict | 17:01 |
facubatista | __chip__, see `bar` in my last pastebin | 17:01 |
__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:02 |
__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:03 |
__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:04 |
__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:10 |
* facubatista bb~1h | 17:23 | |
* facubatista didn't go :p | 17:29 | |
* facubatista bb~1h for real now | 17:51 | |
* facubatista is back | 19:12 | |
=== mup__ is now known as mup_ | ||
__chip__ | ok, i'm out | 21:04 |
__chip__ | facubatista: amañá! | 21:04 |
facubatista | __chip__, chaus | 21:04 |
__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:21 |
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:22 |
facubatista | __chip__, indeed; there +1'ed it | 21:23 |
__chip__ | facubatista: thank you for buying the conflict :-) | 21:23 |
* __chip__ pokes travis | 21:24 | |
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:26 |
__chip__ | facubatista: anything i can review for you? | 21:30 |
facubatista | __chip__, I lost track, tomorrow need to do a pass on everything | 21:30 |
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:31 | |
__chip__ | facubatista: i can resolve that conflict for you if you want | 21:49 |
__chip__ | s/if you want/if you don't mind/ | 21:49 |
facubatista | __chip__, no worries, I will work it out tomorrow | 22:03 |
__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:06 |
facubatista | __chip__, we can stop squashing | 22:08 |
* facubatista hates squashing, it's human solution to a technical problem | 22:08 | |
* __chip__ likes butternut squash | 22:09 | |
* __chip__ zzzs | 22:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!