On Thu, Aug 13, 2015 at 8:12 AM, Stuart Bishop <stuart.bis...@canonical.com> wrote:
> I think the documentation at https://pythonhosted.org/charmhelpers/ is > key here. To aid new authors, we need a reference guide of all the > helpful tools. Even if charm-helpers is split up, I think that we > still need some way of generating this reference as a cohesive whole. > If not, we are back where we started with the original problem > charm-helpers was created to solve - a pile of libraries that > interoperated poorly and developed in isolation, often wastefully > reimplementing each others work. > Agreed. We definitely need a cohesive set of documentation that surfaces work done by various charm authors. I definitely do *not* feel like the current documentation does that. In fact, there were quite a few charmhelpers sub-packages that were not even included in the documentation until recently. Additionally, many of the doc pages are either sparse-to-empty or giant unreadable walls-of-text (though I tried to help the latter by introducing the autosummarytable at the start of the bigger core pages). I think jujucharms.com/docs needs to be a part of this picture, as well. It seems like the right place to have a Greater List of Charm Helpers, including all sub-packages, alternate-language packages, and highlights of new or interesting helpers. I personally don't see any advantages in splitting charm-helpers into > two separate branches. I think it will increase the maintenance burden > and raise the barriers to entry. Splitting it even further, into core, > extras, contrib_a, contrib_b, etc. even more so. From my experience, > this approach just spreads the maintainers too thin, with some > components badly maintained and others totally unmaintained. > I think that it changes the maintenance burden but overall i don't think it increases it. I'm honestly tired of maintaining forks of charm-helpers for various projects, and having already split things out of contrib for those projects, it has become much easier to manage. > I believe they should be integrated into an umbrella project, such as > charm-helpers. If not they will all wither and die. I don't see any of > them being able to support a community. There is no point me releasing > cool stuff of interest to other charmers as a separate branch or > package, as they will never discover it. And if I did, bug fixes or > suggestions will be rare, because it is perceived to be my project and > not their project. > We have a unified Juju and Charming community, and we can work to proselytize each other's work. You can also post to the mailing list, attend charm schools and Juju Office Hours to talk about them, write blog posts, etc. The projects don't have to live in a shared code-base to address that. > For the Pythonic side, I'm mainly thinking of charmhelpers.context > which I have up for review and have used extensively in the PostgreSQL > charm rewrite. I got sick of writing relation_set/relation_get etc. > everywhere, so wrote a higher level API that exposes a big chunk of > the hook environment as dictionary like objects. I personally think it > makes charm code much clearer, and if people agree then I think it > should be in charmhelpers and charmers encouraged to use it over the > low level API provided by hookenv and Juju. But if this was a 3rd > party library, it would never gain traction and I doubt I would get > any feedback on the design at all. I think it is helpful and > interesting, but not enough for people to go out of their way do > discover and use. And it is certainly not the sort of thing to port to > other languages - you could do something similar, but the design would > necessarily be different. > Excellent, I will definitely take a look at this, because I agree with you and I look forward to seeing how you address it. However, there have been several attempts (to varying degrees) at this already in charm-helpers and none of them have gained all that much traction, so I don't think that's really an argument in favor of charm-helpers. I think mentioning it here on the list is much better than just firing-and-forgetting a review that is easily missed by the community-at-large.
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
