Tim, Alex and myself had a short meeting today about the last fortnights charms.reactive discussions.
The major discussion was started by Merlijn in https://github.com/juju-solutions/charms.reactive/issues/102 . The three of us in todays meeting felt the way forward is to abolish the concept of interface layers completely and just have layers. We think that all that is involved is some charm-tools work so that hook stubs are automatically generated for interface implementations pulled in from standard layers, in the same way they are already generated for interface implementations pulled in from interface layers. It could be fully backward compatible, and existing interface layers trivially converted to standard layers when the maintainer chooses. This approach should simplify charms.reactive, and solve a number of issues with interface layers such as code sharing, layering and inability to declare dependencies. I think all that is needed is someone with the time to do the implementation. Although only indirectly related to charms.reactive, we discussed migrating from the charm-helpers module to standard Python modules in the charms.* namespace. This has been discussed in previous years, and just needs people interested in maintaining modules. There no longer seems to be any advantage to having a monolithic charm-helpers. Moving code to new modules in the charms.* namespace would allow us to move forward, drop Python2 and Juju1 compatibility and fixing interface issues without worrying about backwards compatibility, while leaving the mature charm-helpers code to further mature. Per previous emails, discussions are ongoing at https://github.com/juju-solutions/charms.reactive/issues and contributions welcome there or via this list. -- Stuart Bishop <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
