The future of Charm Helpers

Marco Ceppi marco.ceppi at canonical.com
Sun Nov 22 19:23:13 UTC 2015


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.

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.

Thanks,
Marco Ceppi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151122/94fe0d82/attachment.html>


More information about the Juju mailing list