Fwd: The future of Charm Helpers

[Merlijn Sebrechts]

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.



2015-11-23 9:47 GMT+01:00 Stuart Bishop <stuart.bishop at canonical.com>:

> On 23 November 2015 at 02:23, Marco Ceppi <marco.ceppi at 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.bishop at canonical.com>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151123/0f5bada2/attachment.html>