[08:16] goooooooooooooooooooooooooooooooooooooooooooooood morning! [08:35] morning Chipaca [09:45] taking a page from pytest, would 'pip install ops-k8s' feel like a reasonable way to install the k8s ops component? [09:51] Chipaca, ops-k8s or component-k8s both feel good to me [09:51] ops-lib-k8s [09:51] just to brainstorm some things [09:56] ops-lib-k8s sgtm :) [09:59] Chipaca, yeah, I think I like it the most so far [09:59] and it fits the 'opslib' ops.lib stuff [10:08] it's not ready yet but https://github.com/chipaca/ops-lib-k8s exists :) [10:21] oooh, shiny [10:35] Chipaca, do we want people to typically put everything into __init__ or just import it into there? [10:35] It feels odd to have a package that only has an __init__.py [10:35] jam: tbh in this case it could just be a k8s.py :) [10:35] Chipaca, indeed, but does our ops lib support that? [10:35] i'm torn on which one is better [10:35] Also where is LIBNAME, etc [10:35] this doesn't have opslib support yet [10:36] Chipaca, I like that you can grow into having multiple files [10:36] i'll get to that :) [10:36] me too [10:36] but python doesn't care really, k8s.py and k8s/__init__.py are used in the same way [10:37] anyway, right now i'm getting it to work on 3.5 [10:38] python 3.5 doesn't support TLS newer than 1.2 [10:57] Chipaca, *sigh*. given Firefox now needs you to explicitly enable support for older TLS [10:58] Chipaca, out of curiousity, why "k8s_test.py" and not "test_k8s.py" I know we use the latter in ops, but was trying to figure out if there is a standard [10:58] ¡Muy buenos días a todos! [10:59] morning facubatista [11:00] hola jam [11:00] jam: just because i renamed it [11:00] i mean [11:00] i did not rename it [11:00] :) [11:00] jam: i suspect unittest wouldn't find the former, fwiw [11:30] Chipaca, jam, When building replace current hooks that are links to the charm https://github.com/canonical/charmcraft/pull/85 [11:30] PR charmcraft#85: When building replace current hooks that are links to the charm [11:38] Chipaca, jam: The "list revisions from the Store" command - https://github.com/canonical/charmcraft/pull/86 [11:38] PR charmcraft#86: The "list revisions from the Store" command [12:28] AttributeError: type object 'datetime.datetime' has no attribute 'fromisoformat' [12:28] py3.5 hates me [12:52] facubatista: with all its being [12:56] I need to stop this crazy dance of pathlib2 being used in py35, which is 99% the same than pathlib [12:56] * facubatista will propose a branch [13:31] facubatista: standup? [16:47] Chipaca, jam, in my charmcraft#86 branch, we keep "finding the information" from the context, which so far looks nice... if you're in the project, it finds the "charm name" from there... if not, you can use '--charm-name' and its fine [16:47] PR charmcraft#86: The "list revisions from the Store" command [16:48] mhmm [16:48] as it's an "option", it would be "charmcraft revisions --name=myblog", not "charmcraft revisions myblog" [16:48] so far, maybe so good [16:48] however, in the "release" command it gets ugly [16:49] we can still guess the charm name, however the channel and revision are mandatories [16:50] "charmcraft release 5 stable" looks weird [16:50] "charmcraft release 5 stable --name=myblog" looks ugly [16:50] facubatista: 1 sec [16:50] charmcraft release --channel=stable --release=5 --name=myblog [16:50] "charmcraft release --name=myblog --revision=5 --channel=stable" looks like those are options, but not [16:51] with --channel defaulting to edge and --release defaulting to 'last' [16:51] wouldn't that work? [16:51] Chipaca, I don't know "last" [16:51] you can [16:51] by asking [16:51] Chipaca, unless I go and do an extra hit to the store [16:51] why wouldn't you? [16:51] Chipaca, however, isn't this a little dangerous, like releasing stuff to somewhere without the user specifying where? [16:52] that's why i suggested 'edge' be the default for channel [16:52] and not 'stable' :) [16:52] yeah, sure [16:52] facubatista: OTOH you could leave channel as an argument [16:53] and make just revision an option [16:53] but then [16:53] "charmcraft release edge" makes much more sense [16:53] ok :) [16:53] as "last" is the revision that you want to release in the 99% of the cases [16:53] i was about to argue how it was a bit weird, but i'd be just arguing against myself :-P [16:54] facubatista: also as an aside, tab completion for --revision= would be very nice :-) [16:54] and for --name [16:55] but we can talk about that tomorrow (or next week (or...)) [16:55] oh, I forgot about that [16:56] Chipaca, also, channel can be multiple without getting the extra weirdness when it's not alone [16:57] I mean, "snapcraft myblog 4 edge" is ok, but "snapcraft myblog 4 edge beta 3.0/edge" is weird [16:57] "charmcraft edge" is ok, "charmcraft edge beta 3.0/edge" is still ok [16:57] sorry [16:58] I mean, "snapcraft release myblog 4 edge" is ok, but "snapcraft release myblog 4 edge beta 3.0/edge" is weird [16:58] "charmcraft relase edge" is ok, "charmcraft release edge beta 3.0/edge" is still ok [17:21] ok [17:21] facubatista: and --revision=4,5,6 also works [17:21] or --revision=4 --revision=5 [17:21] i prefer the comma-separated one but thats just me :-) [17:22] Chipaca, does it make sense to release multiple revisions at the same time? [17:22] I think it may be easy to confuse [17:22] facubatista: when doing multi-arch, yes [17:22] charmcraft release --revision=3 edge --revision=7 beta [17:23] Chipaca, I think its way more normal to release one revision to multiple channels, than releasing several revisions at the same time [17:25] facubatista: again, when doing multi-arch, you release all the revisions that correspond to one point-in-time build at the same time, usually [17:26] facubatista: but it's not important tbh [17:26] we can nail it down later :) [17:28] ok [20:38] * facubatista eods and eows, will be back on Monday! [20:53] facubatista: have a good one! [20:53] i'm off for today too