=== niemeyer_ is now known as niemeyer [08:07] morning all [08:55] * Chipaca starts pronouncing 'lifecycle' to rhyme with 'bicycle' [09:40] bthomas: why do you like, commas so much 🙂 [09:42] Good point Chipaca :-). I tend to write long complex statements. I was hammered by my dissertation advisor to break them down into smaller statements or use commas for pause. Looks like both you and facundo have indigetion with the consumption of so many commas, so I will cede to the democratic will here :-). Do let me know if the sentenses are complex I will break them down. [09:44] Chipaca: My biggest concern is this. All the big edits suggested by you and facundo I can make it both in the google docs and my local markdown copy. I will try to do the same with the commas too, but not having a robotic attention span this can be error prone. I am not sure what our process will be to convert these docs in to web format. [09:44] bthomas: i agree you should break long statements into shorter ones, but sprinkling commas at random is rarely the right approach [09:45] bthomas: once you asked us to review the google doc, your local copy became irrelephant [09:45] ok [09:49] bthomas: WRT commas, maybe http://www.hemingwayapp.com/ helps? [09:51] Chipaca: That is very cool. I will use it next time. BTW I like Hemingway and John Steinback. [09:52] bthomas: i'm pausing my editing for a while, if you want to review [09:53] (don't remove the CHECKPOINT comment so i can continue) [09:53] Chipaca: on it now [10:15] Chipaca: Do we have a preference in terms - Application or Charm. I can't decide. Pick one. [10:15] bthomas: they are not equivalent [10:15] Chipaca: There is one subtly though the Charm manages the application. [10:15] Indeed I was just typing. [10:15] ok let give it a thought [10:16] bthomas: yes, a charm drives an application, inside a unit -- but juju's "application" is a collection of units [10:16] bthomas: so in general i'd talk about the charm, and only use application when it is very clear which of these two you mean [10:16] ok [10:42] PR operator#412 opened: add __repr__ for EventBase, LazyMapping, and RelationData [11:11] PR operator#413 opened: bail out of main() if use_juju_for_storage=True and unsupported [11:38] ¡Muy buenos días a todos! [12:00] facubatista: 👋❗ [12:01] hola Chipaca [12:01] * bthomas is skipping overtures today - hard at work with docs :-) [12:04] could i get reviews for #412? got another pr coming based on it and would rather not have to do the rebase dance [12:04] PR #412: add __repr__ for EventBase, LazyMapping, and RelationData [12:05] (and it's super easy as reviews go) [12:12] Issue operator#414 opened: Ensure all code has proper docstrings [13:02] * bthomas -> lunch === deej` is now known as deej [15:12] facubatista: WDYT WRT pydocstyle in test_infra? [15:15] hml: 👋 [15:15] Chipaca: hi [15:15] hml: facubatista is probably the person you want to chat with :) [15:15] Chipaca: ty! [15:16] facubatista: i’m trying to charmcraft release to a track/risk combo… but i get “Store failure! Invalid track: testme [15:16] for whatever track i say [15:16] release to a risk is fine [15:17] am i missing a step? [15:17] hml, you can not create tracks at will, it's a errand you need to Store people to enable it to you [15:17] facubatista: interesting. i had no idea. [15:17] facubatista: poor will [15:18] hml, you would need to create a new topic here asking for that, IIRC: https://forum.snapcraft.io/ [15:18] (probably there would be something similar for charms in the future, I don't think there's a process in stone for charms yet) [15:18] facubatista: that's just for now, right? later tracks for charms would be requested in a more charming place :) [15:18] facubatista: okay. [15:18] right [15:19] i’m trying to do juju dev/testing, so more complicated channel release info is needed for my test charms [15:24] hml: https://forum.snapcraft.io/t/process-for-aliases-auto-connections-and-tracks/455/1 [15:25] hml: i'm guessing that's what facundo is suggesting you do [15:34] a suggestion - an error message telling you to get the track approved and added would be helpful! [15:35] instead of an error of invalid track. [16:01] * facubatista -> lunch [16:42] facubatista: when you are back can we have a quick 1:1 10 min. [16:43] Chipaca: are you planning to doing the rest of review today or when you are back next week ? [16:43] bthomas: i'll do it tonight [16:43] if that's ok [16:44] Chipaca: That is good, if possible but don't strain yourself. Since then we can save the reviewed doc for future use and then remove sections facubatista would prefer to have removed. Thereby we would not need to do a second review in the future when we put them back (hopefully :-) ). [16:46] should add if we put them back :) [16:54] I could use a 2nd review for #412 as it has a followup [16:54] PR #412: add __repr__ for EventBase, LazyMapping, and RelationData [16:55] Chipaca: having a look [16:56] Chipaca: this reminds me it would be nice to have and string or machine readable representation for the event descriptor "on" . Something that lists the events currently supported. [16:56] bthomas: intersting idea. file an issue for it plz [16:57] * facubatista is back [16:57] there might be complications but it's worth exploring [16:57] Chipaca: will do [17:01] facubatista: are you free for a couple of mins [17:01] bthomas, sure [17:01] stand up hangout 10 mins . going now [17:02] facubatista: waiting for you [17:02] Issue operator#250 closed: Improve __str__ of developer exposed objects [17:02] PR operator#412 closed: add __repr__ for EventBase, LazyMapping, and RelationData [17:07] PR operator#415 opened: Log event deferral and reëmission [17:08] * Chipaca runs away [17:12] * bthomas switch to non-work laptop [17:25] is it possible to upload a bundle via charmcraft? if so, how to a contruct the files to be uploaded [17:30] not yet [17:33] facubatista: is there an eta on that? do you know if there is another wya to get a bundle into charmhub? [17:33] hml, no ETA, this is the issue where we track it: https://github.com/canonical/charmcraft/issues/128 [17:33] facubatista ty [17:34] facubatista: different topic, how do i set a version? i put a version file in the charm directory and did charmcraft build and upload, but the version was set to the same as the revision, not what i set it too [17:36] interesting, let's see that [17:39] facubatista: https://paste.ubuntu.com/p/Dtb249ycyB/ [17:50] hml, can you confirm that you do NOT have a "version" file in the "build" directory, please? [17:50] facubatista: no, I have a version file. [17:50] jam, Chipaca, any idea why we are ignoring the "version" file in the build? We have `/version` in the `default_juju_ignore` string [17:50] I “DO” have one [17:51] in the build directory? [17:51] or in your project's directory? [17:52] 2020-09-23 14:51:49,717 charmcraft.commands.build DEBUG Ignoring file because of rules: 'version' [17:58] facubatista: i’m not up on the terminalogy, it’s in the same directory as the metadata.yaml and where i run charmcraft build from [17:58] like in the youtube charmcraft build tutorial [17:59] hml, no, it's de "build" directory created by charmcraft when you build it [18:00] hml, alternatively, can you please do `charmcraft -v build` and pass me that, so I can see those logs? [18:01] facubatista: sure. afaik, the directory is like what’s here: https://discourse.juju.is/t/tutorial-using-charmcraft-to-build-upload-and-release-charms/3386 [18:03] facubatista: here’s the output https://pastebin.canonical.com/p/KxnKXCNzgx/ [18:04] right, line 27 is the problem [18:05] facubatista: okay… how do i fix this. there is no version file in the build directory created when i run charmcraft build. [18:06] hml, you'd need to... a) hack the charmcraft source code (I can guide you); b) unzip the .charm, put the file, zip it again, upload it; or c) wait for Monday [18:07] facubatista: rgr. I’ll go with B. ty. should i file a bug? o [18:08] hml, https://github.com/canonical/charmcraft/issues/165 [18:08] (I already did) [18:08] facubatista: ty! [18:14] jam, I requested your review on this one, thanks! https://github.com/canonical/charmcraft/pull/166 [18:14] PR charmcraft#166: Don't ignore important files (like version) by default [18:24] facubatista, commentedv [18:26] jam, but charmcraft should fill it itself in the case it's missing, otherwise we're overruling the author, and that's probably always a bad idea [18:26] if it's there, why not respect it? [18:27] facubatista, so 'revision' can also be there, but is almost always wrong/stale. Same for 'version'. If you unpack a .zip of a charm, you would expect it to be there, but if you then reuploaded that, you would not want to take the stale one IMO [18:30] jam, revision and version are handled diferently; the revision is always indicated by the store, it's an integer, always growing; the version can be any string that the user wants, to represent the proper version of the charm [18:30] the revision will be incremented on each binary uploaded to the store, the version is author responsibility [18:31] we're ignoring a posible "revision" file too (don't know why), but in any case the store will not use that for anything; OTOH the store parses and keeps what's in "version" [18:32] I'm not opposed to having it, but I'm much more in favor of populating it by the build command. [18:33] jam, so you say that if the author indicates that version should be X, we go ahead and push to the store something that will end up in version Y? that's super surprising [18:34] facubatista, you can warn if you want, but I trust a static file on disk much less than the build process [18:37] for me it's matter of trusting the author, not the file; if the author would want automatic versioning, she can always remove the file and let charmcraft take charge [18:37] let's talk about this on Monday with Chipaca [18:38] I commented this ^ in the PR [20:53] * facubatista eods and is off tomorrow, will be back on Friday