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 amount > of code. > I honestly can't understand the argument that the current situation lends itself to discoverability in any fashion. I contribute to charmhelpers and work on many charms, and I have pretty much never looked at contrib because it's a giant mess. However, I don't actually think that splitting it will help discoverability in and of itself, because that just takes one big mess and breaks it in to many smaller messes. But I do think it's a step in the right direction, because it gives the owners of each piece far more freedom to iterate on their part to make it better. Then we'd want to have a central location where we collect and list the individual packages (namespace packages could help here, but an easy registration process, built in to the tooling, would work, as well). This list would link to those packages' documentation (encouraging them to improve their docs; I'm looking at you, http://pythonhosted.org/charmhelpers/api/charmhelpers.contrib.ssl.html) and could even have call-outs for particularly useful packages. > And your test harnesses are already setup for you. It is easy to add >> new cool stuff, and its tests. And those tests get run under both >> Python 2 and Python 3 with the same versions of dependencies and your >> cool stuff is much more likely to work with other peoples cool stuff. >> I know for a fact if things get spit out they will have less rigorous >> testing, and we will end up with tech debt Py2 only modules for >> example, or conflicting dependencies. >> > > If we provide similar scaffolding as we have now for those projects I > don't see why they wouldn't continue this way, if people don't take pride > in their projects they either don't get used or get forked and made better > Agreed. We could create a charm-tools createlib or similar command that provides you with a skeleton with all the scaffolding set up for you. As long as the individual libraries are discoverable (namespaced) or registered (via a make target in the scaffolding, perhaps), then we could (semi-)automatically add them to our testing infrastructure. > On Wed, Aug 12, 2015 at 6:11 AM Stuart Bishop <stuart.bis...@canonical.com> > wrote: > > >> But I don't see the large tree as a problem. Its not unwieldy. And you >> don't have to worry about anything dumped into contrib, except from >> the perspective of if it is worth migrating it to the core area and >> how much work it would be (documentation, ensuring consistency, >> maintainability etc.). I don't see the large tree as a problem because >> you next talk about packaging. >> > The large tree isn't a problem from the user's perspective, it's a problem for the people trying to maintain their specific bits of contrib. It creates a barrier to entry that encourages long-lived forks of charm-helpers and perpetuates the charm-helpers-sync terribleness. > The main reason I will not be using your proposed packages for quite >> some time is that I like to add things to charm-helpers and fix bugs >> while working on my charms. I can't do that if I need to wait for a >> release cycle, even if you could get it down to 24 hours. I will >> remain using charm-helpers-sync.py, until I can switch to nested git >> branches, but that is fine. Packages will still make lots of other >> people's lives easier. >> > Right. This is exactly *why* we want to split charm-helpers. charm-helpers-sync is just about the worst way to solve the dev cycle problem that there is. You mentioned git submodules as an alternative, which would be better, as is jujuresources, "make sdist" and moving a tarball, composer, and any number of other options. But the point is that if we can pare down the number of things in charmhelpers, it makes it much easier for any given component to be iterated on. The number of changes to charm-helpers would settle down drastically once it was pared down, making the dev cycle and packaging issues much more tractable. > I tend to think >> charmhelpers.core should provide wrappers around the juju hook >> environment, matching the documented juju hook environment behavior, >> and required low level primitives you need for writing charms. It is >> the foundation for the rest of charm-helpers, which can provide higher >> level and friendlier interfaces. I believe that these higher level >> tools should be Pythonic. So your cli wrappers can publish >> charmhelpers.core for people insane or uneducated enough to write Bash >> charms, and the trivial charmhelpers.core would be trivially ported to >> other high level languages. But porting the Python decorators provided >> by charmhelpers.coordinator or the Pythonic datastructures provided by >> charmhelpers.context would not be helpful. Nor would porting >> charmhelpers.core.templating, since it is currently Jinja2 specific >> (and why it should be charmhelpers.templating). >> > I actually think that host and hookenv are the things that generally make the least sense to have CLI access to, as they tend to be language-specific thin wrappers around Juju CLI tools or common host operations via existing CLI tools. Although, there can also be some convenience wrappers around those tools that make the interface a bit nicer, and those can be nice to expose to the CLI, so it's not absolute. Anything that solves a higher-order charming problem definitely does benefit from CLI access, but then it probably doesn't belong in core.
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
