I'm very much in favor of breaking up charm helpers as well. I think it ultimately acknowledges how charm developers have chosen to use the library (even if not quite correct), but also allows for a theoretically more organized core library. A few thoughts come up as I read this...
First, the hookenv and other parts of charmhelpers is something that is so essential to writing a python-based charm these days, I would personally making a move for the cornerstone python charm library to use the charms.core namespace, though I get why charms.helper would be used as a close-to replacement. Honestly, I think just reboot and put it in the charms.core namespace - you want to write a charm in python, you need this one library and that's it. Others provide more value, but this one is the core piece. Secondly, I'm mildly concerned with the namespace of choice (using the shared charms. as the parent namespace). There may be a magical python 3ism that resolves the mixed development + packaged use of common code (think pip, virtualenvs, etc), but there were some issues that the oslo components within OpenStack ran into with a shared common namespace ((some are in a blog here <http://blog.nemebean.com/content/whys-and-hows-oslo-namespace-change>, and the spec to remove the namespaces within the oslo packages is here <http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html>). As the libraries are broken up, as I believe they should be, we need to make sure we've carefully considered how we expect some of these flows to work and make sure they work (and preferably well). Maybe its not really an issue, but I'd love to be convinced of that. Thanks, Billy -- Billy Olsen Software Engineer Canonical Ltd On Sun, Nov 22, 2015 at 4:37 PM, Adam Israel <adam.isr...@canonical.com> wrote: > 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 > -- Billy Olsen billy.ol...@canonical.com Software Engineer Canonical USA
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
