Hi Marco On Sun, Nov 22, 2015 at 7:23 PM, Marco Ceppi <marco.ce...@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. > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
