[08:47] <stickupkid> I think bundlechanges shouldn't be a separate repo, I'm starting to think that we should internalise some of our libraries as they're really painful to update.
[08:47] <stickupkid> juju/pkg would make sense
[08:49] <achilleasa> stickupkid: I think bundlechanges should be exposed as an API by the controller; this way we don't have to re-implement it in both the cli and pylibjuju
[08:51] <stickupkid> achilleasa, without doubt, the library part shouldn't be an external package though. It's causing a graph of dependencies
[08:51] <achilleasa> stickupkid: do we know if anyone else is using it?
[08:52] <stickupkid> achilleasa, I wonder if we care?
[09:16] <stickupkid> achilleasa, https://github.com/juju/bundlechanges/pull/65
[09:35] <stickupkid> or manadart :point_up:
[09:36] <achilleasa> stickupkid: got CI errors
[09:36] <stickupkid> achilleasa, fixed em
[09:36] <achilleasa> ah, nvm
[09:37] <achilleasa> done
[09:37] <stickupkid> ta
[11:55] <achilleasa> can I get a CR on https://github.com/juju/juju/pull/11912?
[12:02] <manadart> achilleasa: I can look.
[12:43] <achilleasa> manadart: there might be an issue with my solution. It seems that patching the option list injects the defaults
[13:57] <stickupkid> hml, here is my PR https://github.com/juju/juju/pull/11911
[13:57] <hml> stickupkid: rgr
[15:00] <hml> stickupkid: when can we use charm.v8?  i need schema stuff.  :-)
[15:02] <hml> stickupkid: are you trying to get even for my 5K lines with 450 files?
[15:02] <hml> ha
[15:02] <stickupkid> hml, brings it in with this https://github.com/juju/juju/pull/11911
[15:02] <hml> should have looked at the pr before asking myquestion
[16:09] <hml> stickupkid: can we use the replace functionality in go.mod to change these to charm and not have to keep updating v7, v8 v9 etc?
[16:09] <stickupkid> hml, I think it's bad practice to do that
[16:09] <hml> stickupkid: rgr
[16:09] <stickupkid> hml, but I agree, it's terrible to just update a charm package