[Ecosystem-engineering] The future of Charm Helpers

[James Page]

Hi Marco

On Sun, Nov 22, 2015 at 7:23 PM, Marco Ceppi <marco.ceppi at canonical.com>
wrote:

> Hello everyone,
>
> I'm rebooting this conversation because it never fully came to a
> resolution and since this topic was discussed a lot has happened in the
> Charm Ecosystem. I still hold firm, and a lot of charmers I've spoken with
> agree, that charm helpers has become the opposite which it originally
> helped to solve - a concise and tasteful way to bind Python to Juju. I've
> been considering ways to resolve this, providing a clear way for users to
> author Python charms, while not diminishing the large breadth of helpers
> and methods already created.
>
> A new approach I'd like to present is a clean break from the
> "charm-helpers" name and a transition to a new library, `charms.helper`.
> This name follows the same scheme that the reactive framework does,
> `charms.reactive` and is a way we can continue the practice of producing
> helpers around the charm ecosystem without the need of a monolithic code
> base.
>
> 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.
>

I'm +1 on this approach and I think we should just bit the bullet and get
it done.


>
> This clean break will allow us to correct a few naming mistmatches and
> allow us to incubate a transition period where charm authors can use and
> try these but the current charm-helpers library has charms.helper as a
> dependency and map current `charmhelpers.core.hookenv` to the new
> `charms.helper`. I've already started work on a strawman to demonstrate how
> charms.helper could look and will share that later this week.
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151123/52ac8e78/attachment.html>