On 23 November 2015 at 02:23, Marco Ceppi <marco.ce...@canonical.com> wrote:
> Under this proposal, `charmhelpers.core.hookenv` would more or less become > `charms.helper` and items like `charmhelpers.contrib.openstack` would be > moved to their own upstream project and be available as `charms.openstack`. > They will instead depend on `charms.helper` for previous `hookenv` methods. > This is a cleaner namespace that still providing the discoverability (search > pypi index for `charms` and you'll see the ecosystem basically owns that > space) desired from the current source tree. > With the new charm build pattern and reactive framework this would fit in > nicely as we continue on a "charming 2.0" march for quick, easy, and concise > ways to create charms. I welcome a continued discussion on the subject with > the hope we can reach a consensus soon on the best way forward. One thing is > clear, the current way of maintaining charm-helpers is neither scalable or > manageable. I don't think it matters what you do with the low level hookenv library, as reactive charms should be using a higher level library that sets states appropriately (and mixing calls just means state and hook environment will get out of sync). I think it is worth doing this in tandem with creating charms.reactive.hookenv. It is really, really useful having handlers watching for states like 'leadership.set.foo' or 'config.changed.bar' or 'workloadstatus.blocked', but if layers start using the lower level API then state will get out of sync with the hook environment. Or should everything under the charms namespace be reactive framework aware, with charms.reactive just being where the engine is stored? -- Stuart Bishop <stuart.bis...@canonical.com> -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
