Yes thank you for this explanation.
>From my understanding, and please correct me if I'm wrong, hookenv is a low-level library operating below the reactive framework. A truly reactive Charm has no business in that library. Making that library reactive aware means removing it, since these functions can break reactive functionality. If there is functionality in the hookenv library that is still relevant in a reactive charm, then it should be put in charms.helper. Low-level hookenv functionality used by the reactive framework itself should be clearly separated. For example by putting it in charms.reactive.internal (I don't know the python way to hide internal functionality). Charms who are not reactive aware and need the low-level hookenv functions can keep using charmhelpers.core.hookenv. Kind regards Merlijn 2015-11-23 10:51 GMT+01:00 James Page <james.p...@ubuntu.com>: > On Mon, Nov 23, 2015 at 9:49 AM, Merlijn Sebrechts < > merlijn.sebrec...@gmail.com> wrote: > >> Hi James >> >> >> > Requiring that anything under the charms namespace is reactive aware >> is fine - but lets make that 'aware' not 'required' please. >> >> I'm not sure I understand what you are saying. Could you explain this a >> bit more? >> >> For more context: What I propose is that everything under the Charms >> namespace is reactive aware. Code does not get included in that namespace >> if it isn't reactive aware. From my point of view this would pose no >> problem to the ecosystems that are not yet reactive aware since they can >> still use their current charmhelpers.xyz code. I think devs will assume >> that everything in the charms namespace works together well. >> > > > Well charmhelpers.openstack will want to use charms.hookenv for example - > so charms.hookenv should be reactive aware, but should also be functional > without the reactive framework - does that make things clearer? > > > >> >> 2015-11-23 10:40 GMT+01:00 James Page <james.p...@canonical.com>: >> >>> Hi Merlijn >>> >>> On Mon, Nov 23, 2015 at 9:32 AM, Merlijn Sebrechts < >>> merlijn.sebrec...@gmail.com> wrote: >>> >>>> I'm all for requiring everything under the charms namespace to be >>>> reactive aware. >>>> >>>> It is hard for people who are less involved to make sense of all the >>>> different ways to Charm. It's even harder because some ways get deprecated >>>> faster than they get adopted (services framework). I think it's vital to >>>> have a very clear message to charmers about what the recommended way is. We >>>> shouldn't confuse them by exposing deprecated and risky ways to charm. >>>> Let's bite the bullet and use this namespace change to start over with a >>>> clear message. >>>> >>>> I'd say it like this: use bash or use reactive. Everything else is nice >>>> to have but they shouldn't stumble upon it by accident. >>>> >>> >>> >>> I agree with the clear messaging here, but please lets not dead-end all >>> of the charms that don't use reactive; The OpenStack charmers team and the >>> ecosystem of partners who have charms that integrate into the OpenStack >>> charm set have a large codebase which is not reactive based and won't be in >>> the near term. >>> >>> Requiring that anything under the charms namespace is reactive aware is >>> fine - but lets make that 'aware' not 'required' please. >>> >>> >>>> >>>> >>>> >>>> 2015-11-23 9:47 GMT+01:00 Stuart Bishop <stuart.bis...@canonical.com>: >>>> >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Juju mailing list >>>> Juju@lists.ubuntu.com >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>> >>>> >>> >> >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
