Re: [Ecosystem-engineering] The future of Charm Helpers

Hi Marco On Sun, Nov 22, 2015 at 7:23 PM, Marco Ceppi 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

Re: The future of Charm Helpers

On Mon, Nov 23, 2015 at 9:49 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Hi James > > > > Requiring that anything under the charms namespace is reactive aware is > fine - but lets make that 'aware' not 'required' please. > > I'm not sure I understand what you are saying. Could

Re: The future of Charm Helpers

On 23 November 2015 at 02:23, Marco Ceppi wrote: > 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

Fwd: The future of Charm Helpers

I'm all for requiring everything under the charms namespace to be reactive aware. It is hard for people who are less involved to make sense of all the different ways to Charm. It's even harder because some ways get deprecated faster than they get adopted (services framework). I think it's vital

Re: [Ecosystem-engineering] The future of Charm Helpers

On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen wrote: > 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

Re: [Ecosystem-engineering] The future of Charm Helpers

Cory, Yeah, my understanding is that the namespace support in Python 3 is far improved, and there was some support for it in Python 2.7 which still had some unique issues from time to time. I'll play around with it a bit and if I find anything worth mentioning I'll report back. At the very least,

Re: [Ecosystem-engineering] The future of Charm Helpers

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,

Re: [Ecosystem-engineering] The future of Charm Helpers

On Wed, Aug 12, 2015 at 7:38 AM, Marco Ceppi marco.ce...@canonical.com wrote: I can see how this helps for discoverability for those already pretty intimate with the code base, but a lot of the key complaints we've gotten around new authors getting started is there is just an overwhelming

Re: The future of Charm Helpers

Small comment while mentioning charm-helpers: What I would really like to see is the project's tests running in CI, before things start moving around. The last few times we ran them we discovered many were broken (I suspect people need to put out fires and don't bother running the tests before

Re: The future of Charm Helpers

I personally don't care where the CI runs, as long as it runs :) Adding to that, it should run *for every merge proposal*, not just on trunk (when it's too late). Travis is a time and cost effective way to achieve this, but I'd be more than happy with whatever alternative solution. - Chris On

Re: The future of Charm Helpers

On Wed, 12 Aug 2015 at 12:12 Marco Ceppi marco.ce...@canonical.com wrote: Working with the Juju QA team to add a Jenkins job for test landing is a great idea, one we should certainly do now while we figure the rest of this out. FYI there's an already an outstanding request with Juju QA team

Re: The future of Charm Helpers

On Wed, Aug 12, 2015 at 7:17 AM Adam Collard adam.coll...@canonical.com wrote: On Wed, 12 Aug 2015 at 12:12 Marco Ceppi marco.ce...@canonical.com wrote: Working with the Juju QA team to add a Jenkins job for test landing is a great idea, one we should certainly do now while we figure the

Re: The future of Charm Helpers

On Wed, Aug 12, 2015 at 6:11 AM Stuart Bishop stuart.bis...@canonical.com wrote: On 11 August 2015 at 20:42, Marco Ceppi marco.ce...@canonical.com wrote: # Trimming down charm-helpers The first item, and arguably the largest is a complete reorganization of the current charm-helpers

The future of Charm Helpers

Hello everyone, There have been a lot of conversations had over the past few months about charm-helpers and how to proceed forward with the project. As a result of these conversations I'd like to surface the following items for discussion: # Trimming down charm-helpers The first item, and

Re: [Ecosystem-engineering] The future of Charm Helpers

On Tue, Aug 11, 2015 at 10:00 AM Matt Bruzek matthew.bru...@canonical.com wrote: Thanks for the write up Marco. I am particularly interested in growing the CLI aspect of charm-helpers to aid authors who still use bash charms. Also cleaning up the docs so they make sense and is easier to