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
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju