charms.reactive bi-weekly sync recap

[Stuart Bishop]

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 <stuart.bishop at canonical.com>