The future of Charm Helpers

[James Page]

Hi Merlijn

On Mon, Nov 23, 2015 at 9:32 AM, Merlijn Sebrechts <
merlijn.sebrechts at 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 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.


>
> 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
>>
>
>
>
> --
> 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/a845bd62/attachment.html>