#smooth-operator 2020-05-18
<MarkMaglana> o/
<MarkMaglana> Question: When using the test harness, is there anything special we need to do in our unit test to make this line work in the SUT's code? `self.framework.model.resources.fetch('grafana-image')`
<jam> MarkMaglana, I believe resource support is something that needs to be implemented
<jam> MarkMaglana, I would expect to have some sort of setup on the Harness, where you tell it what paths you should return for a resource request
<jam> MarkMaglana, issue #262
 * jam heads to take the coffee machine to the shop, critical infrastructure :)
<MarkMaglana> jam: thanks for that!
<MarkMaglana> and black coffee for me today, please!
<MarkMaglana> another question. what other steps do i need to perform prior to exposing a k8s workload via `juju expose <app-name>`
<Chipaca> morning all
<MarkMaglana> top of the mornin' to ya Chipaca!
<MarkMaglana> bottom of the afternoon for me though
<Chipaca> *my* morning, all
<Chipaca> :-p
<jam> MarkMaglana, you shouldn't need to do much as a user, you can include "expose" as part of a bundle
<jam> as a charm developer, you need to call 'open-port' in order to tell Juju what to expose.
<jam> Chipaca, good morning
<MarkMaglana> jam: actually i discovered just now that i don't even need to run `juju expose`. I can access the app via its IP directly. but that's only if i access it from within the host. (i'm using microk8s)
<Chipaca> jam: how're things?
<jam> Chipaca, well, coffee machine broke.. so I took it into the shop, but otherwise things are going ok
<Chipaca> /o\
<Chipaca> jam: i too have coffee woes â¦ my postie has gone missing, with now two coffee deliveries missed (and some masks my mum made)
<Chipaca> i'm now down to instant
<jam> Chipaca, ouch! my deliveries have been regular, which is good. And we have a backup nespresso machine that my wife usually uses for decaf
<jam> Chipaca, but if you have instant, you have Dalgona, right?
<Chipaca> on the one hand, yes
<MarkMaglana> cold brew ftw!
<Chipaca> on the other hand, that thing takes ages to make and dirties a lot more than just a coffee
<Chipaca> one of the things i like about my aeropress is the minimal mess
<Chipaca> Â¯\_(ã)_/Â¯
<jam> pretty inexpensive to get a replacement, but you might need to go out of the house for that
<Chipaca> jam: still out of coffee for it tho
<Chipaca> :)
<jam> sometimes you can find places that sell things for money, which sometimes includes coffee :)
<Chipaca> jam: this is true, and i might resort to that if i tire of my instant
<Chipaca> the instant is only ever meant as an emergency ration kind of thing :)
<Chipaca> my delivered coffee is so much better than what i can get in the supermarket, the few times i have bought coffee there it ends up going off
<Chipaca> ANYway
<Chipaca> jam: is my approach on #284, wrt initial values for _status, reasonable? ie having unkown for app and maintenance for unit?
<Chipaca> jam: (and if maintenance for unit, is there any particular message i should set on it?)
<Chipaca> i tried seeing what message juju set but it was beyond my ken still
<jam> Chipaca, works for me
<jam> No message on the unit
<jam> which is why you couldn't find it :)
<MarkMaglana> Chipaca: aeropress is awesome. And I'm still wondering why I haven't bought one. Something is wrong with me.
<Chipaca> MarkMaglana: because you're at a local comfort extreme and getting out of it requires work?
<MarkMaglana> Chipaca: mystery solved!
<Chipaca> boo, 3.5 doesn't like foo: bar = 'baz'
<jam> Chipaca,even if it is "foo: str = 'baz' " ?
<Chipaca> jam: yeah, it's a 3.6ism
<Chipaca> for 3.5 we're stuck with the entirely unsatisfying  # type: str
<jam> Chipaca, I think I still need your review of couldn't find it :)
<jam> <MarkMaglana> Chipaca: aeropre
<jam> sorry bad paste
<jam> https://github.com/canonical/operator/pull/279
<jam> Chipaca, I thought I had done that syntax, but it was probably '=None'
<Chipaca> jam: on it already :)
<Chipaca> jam: i could use one on #190 also
<jam> Chipaca, approved #190, I'd like to see us fix the bits that don't get PYTHONPATH set correctly, etc. but nothing in that is wrong, just doesn't quite 'juju deploy .' with the actual text that was written
<Chipaca> jam: yep, I'm going to be pushing for us to have at least that bit of charmcraft build done before the next biweekly email :)
<Chipaca> jam: which reminds me, did you get to give that a read?
<jam> Chipaca, yeah. it looks good to me, depends a bit on who the audience is. Is it just a Discourse "here's what we're doing" sort of thing?
<Chipaca> jam: and to our mailing list (!)
<jam> Chipaca, isn't Discourse the New(tm) mailing list?
<Chipaca> jam: for this sort of thing, i have 0 problem in posting it to the old *and* the new
<Chipaca> :)
<jam> Chipaca, I just didn't know of an external mailing list that people wanting announcement style messages would be signed up to
<Chipaca> jam: there's probably at most one or two people on the list that aren't watching discourse, but i care for them :)
<facubatista> Muy buenos dÃ­as a todos!
 * Chipaca reading https://www.conventionalcommits.org/en/v1.0.0/ and going "hmm" a lot
<Chipaca> facubatista: how're you doing?
<davigar15> Hey! qq
<davigar15> Do you know if an async action will work in the operator framework?
<Chipaca> davigar15: what's an async action in this context?
<Chipaca> actions work :)
<Chipaca> but i didn't know juju had 'async' actions
<davigar15> ```
<davigar15> async def get_chat_id(name):
<davigar15>     await asyncio.sleep(3)
<davigar15>     return "chat-%s" % name
<davigar15> ```
<davigar15> Coroutine I mean
<davigar15> With asyncio
<davigar15> Chipaca: So instead of having `def on_whatever_action`, we'd have `async def on_whatever_action`
<Chipaca> davigar15: and what would that do?
<davigar15> Well, I don't know about the internals of it, but basically when you put async in a function definition, that function is a coroutine that can `await` to other functions. Is the way to implement asynchronous functions in python
<Chipaca> davigar15: yes, I know. I'm asking what that would do for the charm :)
<Chipaca> davigar15: that is: what is the advantage of it for you, the charm writer
<Chipaca> currently we don't support this, fwiw
<davigar15> In my usecase, I have a charm that SSH to a machine using paramiko. I'd like to remove that dependency, and implement the ssh function this way: https://github.com/juju/python-libjuju/pull/393/commits/7ceb7561b6eb3b070868eb28c4ad47791ae1aa7c
<davigar15> For that I need to `await ssh(cmd)`, and we can only await in coroutines
<Chipaca> davigar15: there's nothing stopping you doing that in the handler
<Chipaca> davigar15: you don't need the event handler to be async for that
<Chipaca> that is, you can write pretty much the same 'async def ssh(...)' and then await ssh() in your _on_foo event handler and it'd work
<davigar15> import asyncio
<davigar15> await asyncio.sleep(4)
<davigar15> ^ If I put that in an event handler, it says: undefined variable: await
<facubatista> mmm...
<davigar15> warning that disappears  when I put `async` in the definition
<facubatista> davigar15, let me try something
<davigar15> ð
<Chipaca> ah, i forgot the await-only-in-async
<Chipaca> davigar15: from python 3.7, that'd be asyncio.run(asyncio.sleep(4))
<Chipaca> davigar15: before 3.7 it's asyncio.get_event_loop().run_until_complete(asyncio.sleep(4))
<facubatista> davigar15, I just tried this as a script, but you can do the parallelism: https://paste.ubuntu.com/p/FBTdb5bVV9/
<Chipaca> facubatista: poncho! :)
<facubatista> davigar15, you'd need to start the event loop on each call, though, and wait for everything to complete before ending
<facubatista> davigar15, and finally, take into account that any call *back to the framework* would be blocking
<facubatista> Chipaca, :)
<davigar15> What do you mean with "would be blacking"?
<facubatista> davigar15, "blocking", not blacking, as "it will not be async"
 * facubatista brb
<davigar15> sorry for the typo. Okay, understood
<davigar15> Thanks :)
<Chipaca> davigar15: sorry if you already answered this, but what is the advantage to you to having your ssh function be async?
 * facubatista is back
<davigar15> Basically I did that in the SSHProvisioner in libjuju, and was to reuse that function here.
<davigar15> I can simply execute subprocess.check_call()
<davigar15> And will be the same
<facubatista> davigar15, but it is an external process the one you're calling?
<facubatista> *is it
<davigar15> I'm doing `ssh <user>@<host>[...] cmd` in the charm
<davigar15> The process is executed in the charm, but it basically does ssh to a machine to execute whatever function
<davigar15> It is what we called in OSM: proxy charm.
<facubatista> davigar15, my point is that the process is NOT executed in the charm, it's a *sub*process
<facubatista> davigar15, so, you would need to wait for it from the charm
<davigar15> yep
<davigar15> exactly
<facubatista> davigar15, so I'm lost in how async helps you here
 * facubatista is trying to understand, but it's so early in the morning here :)
<davigar15> Only to reuse the function I already made. Don't worry, you solved my problem
<davigar15> As I need to wait anyways, it doesn't help me at all
<facubatista> ack
<Chipaca> one interesting thing for me, looking into this, is that there isn't AFAICT a way to tell a function from an async function before calling it
<Chipaca> oh, inspect.iscoroutine
<Chipaca> and iscoroutinefunction
<Chipaca> fair'nuf
<Chipaca> i first looked for async and only got isasyncgenerator[function]
<facubatista> Chipaca, I can not land charmcraft branch because "The base branch requires all commits to be signed", I'm reading about this (how to do that), but just telling you in case we have something misconfigured
<Chipaca> hmm
<Chipaca> facubatista: it's a toggle
<Chipaca> facubatista: want me to un-toggle, or do you want to start pgp-signing commits? :-p
<Chipaca> i'll toggle it as i suspect i may be the only one signing commits here
<facubatista> Chipaca, I can sign them
<facubatista> if I understand how :)
<Chipaca> facubatista: made optional for now :)
<facubatista> Chipaca, what I don't understand is if I need to sign the commits in my branch, or sign the commit which merges my branch into master
<Chipaca> facubatista: git config user.signkey "somekeyid", and git config commit.gpgsign true
<Chipaca> facubatista: from memory
<facubatista> Chipaca, but that would sign the commits in *my branch*, not in master, is that what is needed?
<Chipaca> facubatista: it'll sign your commits locally
<Chipaca> facubatista: not on master, but i changed settings on charmcraft to use merge commits
<Chipaca> facubatista: let's see how that works
<MarkMaglana> > 16:32:32 <jam> as a charm developer, you need to call 'open-port' in order to tell Juju what to expose. <-- jam does this apply to k8s charms as well?
<Chipaca> oh dang lunch
<facubatista> Chipaca, yay, I'm now "Verified"
<Chipaca> facubatista: â
 * facubatista adds a â to own CV
<jam> MarkMaglana, I'm not sure, as I believe part of the spec for the pod is what ports it is using. I haven't actively tested it either way.
<Chipaca> jam: one thing we looked at and confirmed with facubatista on Friday
<Chipaca> jam: is that Optional is not needed, as it's inferred automatically from =None
<Chipaca> jam: which is nice :)
<Chipaca> as in, if you have a =None, it'll be Optional
<MarkMaglana> jam: yeah i suspected that was the case.
<Chipaca> jam: surprisingly we have something marked Optional that _isn't_ =None
<jam> Chipaca, I think we have a couple things with default values, hence optional
<jam> ActiveStatus(message=''a)
<jam> etc
<Chipaca> jam: hmm. I think Optional just means 'can be None', not 'has default values'; the default values need to match the explicit types (unless they're None, which makes the explicit type get promoted to Optional)
<Chipaca> facubatista: any chance for a review on 284?
<facubatista> Chipaca, I was about to start my round on issues and prs
<facubatista> I'll start with 284, then
<Chipaca> facubatista: also, you could land #273 :)
<Chipaca> except conflicts
<facubatista> Chipaca, +1, with comment
 * facubatista -> quick lunch before meeting
<vgrevtsev> hi team, have a quick question: what's the right way to write a relation data inside of the event handler? I'm getting a "TypeError: 'Relation' object is not subscriptable" and I bet I'm doing something wrong...
<Chipaca> vgrevtsev: relation.data[...] ?
<Chipaca> vgrevtsev: instead of relation[...]
<Chipaca> vgrevtsev: i guess :)
<vgrevtsev> Neither `event.relation` using `event` object in the handler nor self.model.relations[_rel] .. didn't work
<vgrevtsev> Ahh, `relation.data`, alright
<Chipaca> vgrevtsev: 1 sec
<vgrevtsev> Let me try
<Chipaca> vgrevtsev: https://operator-framework.readthedocs.io/en/latest/#ops.model.Relation.data
<vgrevtsev> ok, so `event.relation.data['foo'] = 'bar'` should work then?
<Chipaca> vgrevtsev: event.relation.data[event.unit]['foo'] = 'bar'
<Chipaca> no wait
<Chipaca> that's the _other_ side, you can't write to that
<Chipaca> vgrevtsev: event.relation.data[self.model.unit]['foo'] = 'bar' :)
<Chipaca> that's the one you want
<Chipaca> event.unit won't be "you"
<Chipaca> so you can't write to it
<vgrevtsev> well, so I can use [event.unit] to read the remote relation data being written by another charm (from another side of the relation) ?
<Chipaca> yep
<jam> Chipaca, I can see that is what it means to 'typing', but that isn't what Optional means to me as a person
<Chipaca> facubatista: you there?
<facubatista> yes
<Chipaca> facubatista: ok :)
<facubatista> fighting auth
<vgrevtsev> Chipaca: can a `ops.model.RelationDataContent` be casted to the regular dict to iterate over the relation data? (that's what I got after calling the `event.relation.data[event.unit]`)
<Chipaca> vgrevtsev: ops.model.RelationDataContent is a MutableMapping, just use it as you would a dict and it should do the right thing
<vgrevtsev> ah I see, will try, thanks a lot!
<Chipaca> vgrevtsev: https://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping if that helps
<vgrevtsev> I'm on it atm :)
<Chipaca> it's also a LazyMapping, which is the same thing but lazier ;-p
<vgrevtsev> that helps - it tells me that .keys() and .items() are implemented in Mapping
<vgrevtsev> so I can use them ^_^
<vgrevtsev> nice, that works, thanks again Chipaca :)
<Chipaca> I am *so* happy we went with sphinx for the docs!!!
 * Chipaca sings a ballad to intersphinx
<Chipaca> with #285 things like MutableMapping will be a link straight into python 3's docs about that :-D
<Chipaca> anyhoo, EOD for now. I'll bbl to tinker with ops.lib but might not come onto IRC as I need to do a large refactor to get things testable
<Chipaca> ð
<facubatista> Chipaca, bye
 * facubatista eods
<MarkMaglana> what? but i just got here! was it something i said??
#smooth-operator 2020-05-19
<jam> morning all
<MarkMaglana> morning jam !
 * Chipaca pokes the internal irc
 * Chipaca presents footage of said event: https://www.youtube.com/watch?v=JMJXvsCLu6s
<jam> morning Chipaca
<Chipaca> jam: how's things?
<jam> going alright here.
<jam> Chipaca, they just called to tell me my coffee machine should be fixed by tomorrow, whi
<jam> which is pretty good news.
<jam> Though the repair cost is ~ the same as an aeropress :)
<Chipaca> I'm probably going to jinx it, but my aeropress is 6+ years old and still working just fine :)
<Chipaca> niemeyer: hiya! two questions about 'ops.lib.use': one is if you have a strong preference for LIB vs LIB_. The other is whether API/PATCH are the right names for what semantic versioning (which we encourage) is calling MAJOR and MINOR
<Chipaca> patch in particular seems strange as it's the name of the third element (the z in x.y.z)
 * Chipaca is not blocked by these questions and goes back to writing tests
<niemeyer> Chipaca: major and minor mean nothing to most people.. API and patch versions has a stronger semantic
<niemeyer> Chipaca: My preference is obviously for the existing names otherwise I'd not have used them, but it's certainly subjective
<niemeyer> (in terms of the underline, that is)
<Chipaca> niemeyer: ok
<Chipaca> niemeyer: sometimes it feels like it's too mashed together without the _, but sometimes it's fine
<Chipaca> it's *very* subjective :)
<niemeyer> These names will be always seem next to each other..
<niemeyer> Just type them out and look at them for a moment
<Chipaca> niemeyer: yeah, i think they feel weird when writing the tests, but not too weird in the init file itself, which is probably the right way around for weird
<niemeyer> Looked better without, since the whole prefix is mostly noise in that case.. but I won't argue too much in either direction :)
<Chipaca> niemeyer: another q: what about API or PATCH being 0?
<Chipaca> that's ok, right?
<niemeyer> Chipaca: Yeah, sounds fine
<facubatista> Muy buenos dÃ­as a todos!
<jam> morning facubatista
<facubatista> hola jam
<Chipaca> jam: we should add a test for dispatch + independent action
<jam> Chipaca, indeed. Though it should follow the same logic as the hooks/ independent script (AFAICT)
<vgrevtsev> hi team, a quick q: do we have a way to alter the "Ports" in the `juju status` output after the charm is deployed?
<jam> vgrevtsev, that is generally populated from calling "open-port", IIRC
<vgrevtsev> I can't find any reference to the `open-port` in the framework code, so I'm wondering how it's getting done and how can I invoke it within the charm code
<vgrevtsev> I doubt that the `open-port` is available using the k8s charms.. at least I tried to run it inside the operator pod and got nothing
<Chipaca> vgrevtsev: https://github.com/canonical/operator/issues/179
<Chipaca> so no surprise you don't find it yet :)
<Chipaca> i don't know about the k8s side of your question though
<vgrevtsev> Ok, so at least something! ;D
 * facubatista brb
<facubatista> jam, which is the minimum set we need? (as the OF itself adds other hooks, right?)
<jam> So a minimum to be forward and backward compatible is probably dispatch + start + upgrade-charm
<jam> I think those are all the entry points that you could hit
<facubatista> jam, no "install"?
<Chipaca> facubatista: yes, also install
<facubatista> I included it just in case
<Chipaca> :)
<facubatista> So, First version of the build command: https://github.com/canonical/charmcraft/pull/4
<facubatista> and with that, /me eods
<Chipaca> facubatista: huzzah
<Chipaca> facubatista: have a good'un!
#smooth-operator 2020-05-20
<jam> morning all
<jam> facubatista, you don't need 'install' because if you are on 2.7 it will only call 'start' and if you are on 2.8 it will only call 'dispatch'
<Chipaca> moin moin
<jam> morning Chipaca, how goes?
<Chipaca> jam: a lovely day to just sit by a lake and watch the waves lick the shore
<Chipaca> not feeling particularly energetic
<jam> Chipaca, get pumped!
<jam> did that help ? :)
 * Chipaca reaches for the bicycle pump
<Chipaca> and then do _what_ with it?!?
<jam> Chipaca, doesn't that already make you feel more energetic?
<Chipaca> y
<Chipaca> :-p
<Chipaca> jam: how are you btw?
<jam> (disclaimer: do not inject a pump directly into your skin, do not look sideways at pump, do not engage with BicyclePump(tm) without written consent from your doctor)
<jam> Chipaca, model_name = '' would be valid, though I like None as breaking stuff rather than silently not doing what you want
<jam> Though if you go back to the thread about "when should we error" there may be a reason to not raise exceptions
<jam> Chipaca, I just noticed. I'm doing well. I did run into something odd
<jam> So in StatusBase, we actually don't populate the map until you instantiate an instance (the population is done in __new__)
<jam> which means that your new test it test_testing.py fails if you run *only* that module
<jam> ./run_tests test/test_testing.py
<jam> do we need a Meta class so that inheriting from StatusBase adds it to the map instead of creating an instance?
<jam> I'm a bit surprised we don't run into problems at runtime with someone checking Unit.status and it not know about 'unknown' or some other status type
<jam> Chipaca, this https://paste.ubuntu.com/p/fHJsQ66Ydm/ "fixes" it, but I think it is just papering over the problem
<jam> Chipaca, I filed https://github.com/canonical/operator/issues/288 so I don't forget about it.
<Chipaca> jam: thanks
<Chipaca> my brain is in a different castle rightnow
<jam> Chipaca, np. btw I had a response to "do we need an install symlink" which I don't think we do, bring it up sometime when you're ready to think about it
<Chipaca> jam: why don't we need an install symlink?
<jam> Chipaca, the version of Juju where 'install' is called is also the version that supports 'dispatch', IIRC
<jam> so you need install or dispatch, but not both
<jam> Chipaca, I know we have the meeting with Tom in a bit, do we need to do another prep session for that
<Chipaca> jam: that's just in k8s though, right?
<Chipaca> jam: outside of k8s it's install and upgrade-charm
<Chipaca> inside of k8s its start and upgrade-charm
<Chipaca> for pre-2.8
<jam> Chipaca, right, 'install' for non-k8s and 'start' for k8s
<Chipaca> jam: so without knowing more, you need all of 'em
<jam> Chipaca, yeah, I was thinking through how to communicate it. It feels bad to populate a lot of things "just in case" and then have the framework be populating the rest.
<jam> Chipaca, btw, for the meeting with Tom, should we be doing prep work for that?
<Chipaca> jam: this is a first meeting (tom is proxying paul collins)
<jam> gotcha, I see that now in the notes
<jam> Chipaca, are we intending to copy that over to the charmcraft calendar?
<Chipaca> jam: i was hoping to get that handed over so we could move it there, yes
<Chipaca> copying is not useful as it doesn't carry moves etc over
<jam> Chipaca, sure. "replacing with a copy". (I'm not able to edit the description to add the notes doc, etc.)
<Chipaca> actually, let me try to sort that now :)
<Chipaca> mthaddon: would you mind passing ownership of the calendar event for today's meeting to me? that's inside Edit, under More actions (beside save), at the bottom
<mthaddon> Chipaca: sure, done
<Chipaca> of course then i need to add /b/1 to the URL the calendar tells me to click :)
<Chipaca> mthaddon: thanks!
<Chipaca> jam: all sorted
<jam> added the doc
<jam> Chipaca, thanks
<facubatista> Muy buenos dÃ­as a todos!
<jam> Chipaca, coming?
<jam> morning facubatista
<facubatista> hola jam :)
<Chipaca> jam: yeah, somebody came to the door
<Chipaca> WOO I GET TO HAVE LUNCH
 * Chipaca hugs mthaddon 
<mthaddon> o/
<Chipaca> jam, facubatista, the reason we don't have a postgres meeting next week is because we're down two people on the monday :)
<jam> Chipaca, I responded to 208, I'm curious whether we want to close it/tag it/something else
<Chipaca> jam: tag it enhancement for now at least
<Chipaca> later we might have an opslib tag
<Chipaca> jam, facubatista, actually we're down 3/3 next monday
<jam> may 25th international holiday (of mystery)
<jam> Chipaca, standup?
<Chipaca> yep 1 sec
<stub> (and I've been doing reactive stuff, so no point)
 * Chipaca hugs stub 
<Chipaca> stub: we still like you even if you're working on other stuff
<Chipaca> â¦ for now
<stub> I'm less trouble when I'm working on other stuff ;)
<Chipaca> stub: I cannot comment on that
<Chipaca> facubatista: you got 5?
<facubatista> Chipaca, yes
<jam> he might even have 6
<Chipaca> gasp
<Chipaca> jam: hey if you've also got 5, let's meet in the standup thing
<facubatista> omw
<facubatista> jam, Chipaca, I don't like "directory" as the option name for the charm's project base directory, "directory" is way too generic
<Chipaca> facubatista: FWIW that one seems strange to me WRT having it in the config file
<facubatista> "basedir"? "base-dir"? "charm-dir"? (this may be confused with the "src" dir which is not what we mean) "project-dir"? "project-basedir"? "project"
<facubatista> ?
<Chipaca> facubatista: let's see if gustavo has opinions on this :)
<Chipaca> facubatista: --from <directory>, --at <directory>
<Chipaca> facubatista: charmcraft build --what ./this
<facubatista> the "from" is nice after the "build" verb
<Chipaca> yep
<Chipaca> --at has the same thing, but it's less directional which might be confusing (is it going to read from that, or put the charm there?)
<facubatista> Chipaca, I started the "config files" issue and end up writing a lot there :/
<facubatista> Chipaca, https://github.com/canonical/charmcraft/issues/5
<Chipaca> facubatista: ok, I'll read it later :) now I'm going to run away
<Chipaca> facubatista: or maybe I'm going to go away, and run
<Chipaca> facubatista: you decide :-)
 * facubatista decided
#smooth-operator 2020-05-21
<Chipaca> good morning all!
<jam> Chipaca, morning chipaca, how goes ?
<jam> btw, I was quite impressed how much text you churned out
<Chipaca> jam: goes well! brain isn't booted yet but getting there
<jam> Chipaca, I have my coffee machine back, want the first cup ?
<Chipaca> jam: i got my coffee delivered! there's still last week's delivery missing but i'm back in stock at least
<Chipaca> jam: woke up in the night when it clicked that we could use charmcraft.yaml to have an 'install' section for the non-python reqs
<Chipaca> *hand waving intensifies*
<jam> no unicode jazz hands
<Chipaca> ð no?
<jam> "open hands" isn't quite jazz hands to me but good enough ð
<jam> jazz hands aren't next to each other
<Chipaca> "ð¤" is supposed to be "hugging face"
<Chipaca> but "hugging face" is that face-hugger alien parasite thing
<Chipaca> so no thanks
<jam> "hugging face" isn't that choking someone?
<jam> I know I don't usually hug with narrow hands
 * jam lunches
 * Chipaca is having way too much fun
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: ð :-)
<Chipaca> we're lying liars: we're not logging events when dispatch is in use :-( i'll file a bug
<facubatista> Chipaca, Natalia is gmt+3, Moscow
<Chipaca> natalia is also gmt-3, uruguay
<facubatista> :)
<Chipaca> a conspiracy of natalias
<facubatista> mirrors!
<facubatista> speaking of that, I'm no longer the one and only Facundo
<facubatista> #eselacabose
<Chipaca> facubatista: whaaaa
<Chipaca> facubatista: sacrilege!
<facubatista> indeed
<Chipaca> facubatista: and their irc nick is cooler than yours
<Chipaca> facubatista: oh the shame
<facubatista> :)
 * Chipaca goes to make lunch
<Chipaca> grah
<Chipaca> need to take a break before testing the last bit :) and then some failing integration ones and then i'm done
 * Chipaca steps away for a while
<facubatista> Chipaca, something I hate about pathlib.Path is that if you print its str(), it may be misleading (spaces in the middle, etc), but if you print its repr(), the whole "pathlib.Path" is shown... I end up doing "path: {!r}".format(str(path))
 * facubatista bb~1h
<Chipaca> facubatista: I didn't understand why spaces in the middle would be misleading, but that's ok, you can be wrong :-p
 * facubatista is back
<facubatista> Chipaca,
<facubatista> >>> p1 = pathlib.Path("foo bar")
<facubatista> >>> p2 = pathlib.Path("baz")
<facubatista> >>> print(p1, p2)
<facubatista> foo bar baz
<facubatista> ugly: >>> print("{!r} {!r}".format(p1, p2))
<facubatista> PosixPath('foo bar') PosixPath('baz')
<facubatista> what I end up doing: >>> print("{!r} {!r}".format(str(p1), str(p2)))
<facubatista> 'foo bar' 'baz'
<Chipaca> facubatista: y tho
<Chipaca> in what context is 'print(p1, p2)' something you'd actually want to do?
<facubatista> Chipaca, it was an example
<Chipaca> ok
<facubatista>             raise CommandError("the charm entry point was not found: {!r}".format(str(arg)))
<facubatista> Chipaca, ^
<facubatista> Chipaca, think for example if you called it like --entrypoint="mycharm.py "
<facubatista> of course the last space is a type
<facubatista> *typo
<facubatista> >>> print("the charm entry point was not found: {}".format(arg))
<facubatista> the charm entry point was not found: mycharm.py
<facubatista> >>> print("the charm entry point was not found: {!r}".format(str(arg)))
<facubatista> the charm entry point was not found: 'mycharm.py '
<Chipaca> facubatista: hmm. repr in this context is something that is almost but not always what you want for strings even
<facubatista> of course, I won't be using print, but logging it, but it's the same
<facubatista> Chipaca, why I don't like it?
<facubatista> s/like/want/
<Chipaca> facubatista: consider what happens if you specify a filename that's not ascii, and you need it to be ascii
<Chipaca> facubatista: repr won't help highlight the problem
<facubatista> Chipaca, what do you mean "need it to be ascii"?
<Chipaca> e.g. "the filename must be a-z0-9: {!r}".format("ÑÐµÐ°ÑÐµ")
<Chipaca> facubatista: that won't say what the problem is in any way, for most users
<Chipaca> some might though
<facubatista> Chipaca, getting the pathlib.Path() in the middle won't improve that either
<facubatista> Chipaca, you say to just use str() because there are corner cases that repr() won't be enought?
<facubatista> *enough
 * facubatista is too tired to write properly 
<Chipaca> facubatista: no, I'm saying that relying on repr() is sloppy :)
<Chipaca> facubatista: the fact that it mostly, but not always, works for strings has made you think it's ok to do but it isn't really
<Chipaca> facubatista: i'm not sure i'm making sense either
<Chipaca> it's been a long week and there's a whole 'nother day of it to go still
<facubatista> Chipaca, I'd love to find a repr_posta_posta() :)
<facubatista> I don't want to start marking differently every non-ascii char, it would mess up the error message for people using mostly non-ascii stuff
<MarkMaglana> whoa i caught you guys still awake!
<MarkMaglana> ...right?
<MarkMaglana> no?
<Chipaca> MarkMaglana: "awake"
<MarkMaglana> kina awake then?
<Chipaca> MarkMaglana: fractionally awake
<Chipaca> MarkMaglana: not actually working
<Chipaca> at least, me
<Chipaca> facu might be at it still
<MarkMaglana> i just woke up at 4AM my time to check on my tomb raider download. so i won't be working either for an hour or two.
<facubatista> MarkMaglana, which tomb raider?
<MarkMaglana> don't laugh
<MarkMaglana> the first one of the reboot.
<facubatista> MarkMaglana, you're talking about the videogame or the movie?
<MarkMaglana> the videogame lol
<facubatista> ah, jajaja
 * facubatista never played tomb raider
<facubatista> actually, I remember installed and tried one, like 300 or 400 years ago, and my HW was too slow for it, and I dropped it, never tried again
<MarkMaglana> facubatista i've been wanting to play this since it came out but with family duties it was impossible. also, i was too cheap to buy a powerful enough machine to handle the graphics until this year. so with all this lockdown and all i figured it'd be a good time lol.
<facubatista> :D
<facubatista> MarkMaglana, enjoy it!
<MarkMaglana> facubatista: thanks!
<Chipaca> facubatista: you should be able to play the original one on qemu on a raspberry pi
<Chipaca> :)
<Chipaca> anyway, i'm out
<Chipaca> ð
<MarkMaglana> \o alrighty folks, i'll take it from here lol
 * facubatista eods
#smooth-operator 2020-05-22
<jam> MarkMaglana, I thought the reboot was pretty good. I enjoyed the new Tomb Raider
<MarkMaglana> jam: yeah i'm liking it a lot. the seamless transition from gameplay to cinematics is pretty cool. very immersive. i'm going to have to purchase the rest of this trilogy lol.
<davigar15> FYI: In the OSM Community Slack there are people writing me saying that python-operator framework seems much easier that reactive
<davigar15> qq: Is there any already existing ansible library to use with the op framework?
<davigar15> similar to the ansible-layer in reactive
<Chipaca> davigar15: there is not
<Chipaca> davigar15: good to know about the osm community slack
<davigar15> Chipaca: Is there a way to install dependencies? Charmhelpers for instance
<davigar15> Or do I need to add it as a submodule
<Chipaca> davigar15: there is not, yet, a framework-provided way, no
<Chipaca> facubatista: #244 ready for review :-)
<mup_> PR #244: ops library support <Created by niemeyer> <https://github.com/canonical/operator/pull/244>
<Chipaca> grah, of course pep8 hates it
 * Chipaca fixes
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: o/!
<facubatista> hola Chipaca
<facubatista> Chipaca, if you do "FOO=1 ./stuff.py", you don't really need to "export" that envvar for stuff.py to see it, right?
<Chipaca> facubatista: right
 * facubatista brb
 * facubatista -> lunch
<Chipaca> I'm wrapping things up here
<Chipaca> facubatista: have a great weekend!
 * Chipaca EOWs
 * facubatista is back
 * facubatista eods and eows, and I'm off on Monday, so see you all on Tuesday!
