Just to clean up some loose ends in this thread.
With the new ops.framework you can import pure-Python libraries published by other charmers, which offer up functions and classes that are useful for integrating your charm with their charm. We call those ‘charm libraries’ and charmhub.io pages for a charm will explicitly list them if the publisher has shared any. There is tooling in
charmcraft to fetch and update these charm libraries in your own charm tree, so you always have the latest point version that matches your selected major version of those libraries.
@extraymond you described this as ‘subclassing the charm’ which is not quite right. You import the charm library. You may well subclass a class from the charm library For example, the charm library for MySQL might offer you a class like SingleRequiredDBEndpoint which is ‘an object that reflects the database related to an endpoint, where it is an error to have no database related, and equally an error to have more than one database related’.
The idea is to have the MySQL charm author do all the work for you, so that you just handle the event where ‘the single database I was expecting is now available’ as well as any other events for things like failover moments or situations where theat database gets made readonly for upgrade purposes, etc.
The idea is to stay pure Python, and feel native. Of course, as Eric says, there is value in proof-of-concept bash charms too! But we’re focused on committed product-grade charms, where Python and these library and test mechanisms really improve the experience of your devops.