search

canonical / is-charms-contributing-guide

The code contributing guide for the IS charms team
Apache License 2.0
2 stars 1 forks source link

Separate code from charm class #33

Open jdkandersson opened 1 year ago

jdkandersson commented 1 year ago

Charms have an interface class that derives from the CharmBase class. Many charms currently write most of their logic within that class rather than separate at least some of it to a separate module. The standard would be to only include code relevant to managing the interface with juju to the class inheriting from CharmBase and put the other code into separate modules and functions. This would simplify testing and also generalise logic in the case of having to switch frameworks again in the future. This would also help with migrating charms from previous frameworks.

jdkandersson commented 1 year ago

@gregory-schiano any thoughts?

gregory-schiano commented 1 year ago

I like this idea, as indeed it'll be easier to unit test and also reduces the coupling with the framework. But I have the feeling that it won't be very easy as the charm code depends a lot on ops and pebble abstracting them to decouple the charm business logic could be a bit tough. Could worth a try on a simple charm !

jdkandersson commented 1 year ago

Yeh sounds good, I'll keep an eye out for opportunities to test this in PRs and maybe write an experimental PR for Indico if I get the chance