I am very much in favor of this move forward. I’ve recently worked on converting the charm-benchmark package to charms.benchmark; I see where having cleaner namespaces make will make every charm author’s life easier.
That said, I know that transitioning to this new model is an epic undertaking, especially with the changes coming in the next LTS, i.e., no python 2 by default. To that end, I’d propose some kind of compatibility report be generated (as part of the upgraded CI, perhaps) that notifies charm authors of upcoming changes and how their charm fares against the new requirements. The last thing I want to see as a ~charmer is Xenial come to pass and having to engage in firefighter mode to fix incompatibilities. Adam Israel - Software Engineer Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure > On Nov 22, 2015, at 2: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. > > 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 > -- > Mailing list: https://launchpad.net/~ecosystem-engineering > Post to : ecosystem-engineer...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ecosystem-engineering > More help : https://help.launchpad.net/ListHelp -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
