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 committing).
Could we consider moving to i.e. github.com with travis? It's there, it works, and somebody else is maintaining it (for free, no less). - Chris On Tue, Aug 11, 2015 at 3:42 PM, Marco Ceppi <marco.ce...@canonical.com> wrote: > 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 arguably the largest is a complete reorganization of the > current charm-helpers code base. Originally, charm helpers was setup to > allow a path for developers to place unstable code (contrib directory) where > they could iterate without a guarantee of API stability. However, this > quickly grew to include code that simply didn't make sense as a "core" > feature of charm-helpers. This includes a large set of code for domain > specific charm ecosystems (bigdata, openstack, storage) as well as quickly > fixes to missing features in Juju (leader election). > > The amount of collaborative code in contrib is fantastic! However, it's > making the release and distribution of charm-helpers more complicated. With > an inability to keep up with documentation for methods contrib and the > "volatile" nature of "unstable API", I'd like to propose we completely > remove the contrib directory and instead urge code maintainers in contrib to > create their own libraries for the feature and code they wish to maintain > going forward which simply depends on charm-helpers for the code in core. > > This will allow groups like bigdata, openstack charmers, storage, and others > to maintain their own release and review process for helpers specific to > their solutions, as well as their own means of delivery (be it > charm-helpers-sync, pypi, debian, or another means). This will also GREATLY > slim down the charm-helpers library to instead include one of two things: > > - API in Python for communicating with Juju > - Simple collection of tools in Python to solve shared universal problems > > Which roughly translates to hookenv.py, host.py, and fetch tools. Once > contrib is removed and relocated I'd like to also propose flattening the > library namespaces from > > charmhelpers.core.hookenv -> charmhelpers.hookenv > charmhelpers.core.host -> charmhelpers.host > charmhelpers.core.files -> charmhelpers.host > charmhelpers.core.fstab -> charmhelpers.host > charmhelpers.core.sysctl -> charmhelpers.host > charmhelpers.core.kv -> separate project? > > Everything else, outside of contrib would remain the same. While I think > it's important to slim down charm-helpers I'm not convinced the above > outlined rename/code merges are the right or best way forward. I welcome > feedback and a discussion around this. > > # Packaging charm-helpers > > Currently, charm-helpers are available via either bazaar source or PyPI. > With a more stable, slim, and maintainable code base we would like to > package charm-helpers still on PyPI with semantic versioning, make a > dist/wheel[0] available for embedding (instead of charm-helpers-sycn), and > in Debian and have them available via a PPA but also potentially in the > archive proper. > > The hardest challenge will be keeping the archive as up to date as possible > with releases of charm-helpers. Since charms and Juju versions are decoupled > from packages "frozen" in the archive, just having a version of > charm-helpers in the archive for the version of Juju in that archive won't > necessarily last the test of time. Someone deploying a charm now from a new > version of Juju against trusty would get the 1.21 equivalent of > charm-helpers which may not include the new leadership or extended status > methods causing the charm to fail erroneously. > > Having a PPA can alleviate this, but PyPI and PPAs may interfere with > firewalls and policies where Juju is being deployed. Opinions on how to help > with this are appreciated. Otherwise, we may simply recommend authors to use > a bit of bootstrap code which attempts to install from PyPI, with a fallback > to install an embedded version of charmhelpers that was included in the > charm as a dist/wheel. > > # Charm-helpers for other languages > > We already have charm-helpers written for three languages! Python[0], > PowerShell[1], and Rust-lang[2]. By sliming down the charm-helpers we can > define a minimum requirement that each new charm-helper language should > expose. This will enable us to document charm-helpers more thoroughly and > include code examples for each language supported in our docs. Also, by > having a narrowly defined scope of methods, it enables other communities to > create helpers for their languages. > > The PowerShell library was written by the folks at CloubBase, I had the > chance to sit down with them a few months back and review how their > structure looks. It's already very far along, includes unit testing, and > matches the relative structure we have had in the Python charm helpers for > some time. Going forward I'd like to continue this trend and sent some > guidelines around future charm-helper libraries for other languages. > > # More exposure via the CLI > > Finally, we have a CLI interface for the charm-helpers python library. > Recently there have been several merges which add exposure to additional > methods and features of python charm-helpers. I'd like to continue this tend > and add a CLI hook for everything in charm-helpers, within reason. A recent > addition, by Cory Johns, enabled the internal key-value store in > charm-helpers to be accesible via CLI. While making things like the > "config_get" method available by CLI is silly, other key and core methods > that exist as code in Python only and aren't a 1:1 bridge to Juju commands > should also be made available. This will allow authors creating first drafts > of charms in bash to access these higher methods. > > # Conclusion > > I welcome discussion, dissent, and suggestions around these topics. They are > by no means set in stone but are the assumed plan at the moment. > > TL;DR: I want to make charm-helpers very slim, versioned, packaged, > documented, and easily portable to other languages. > > Thanks, > Marco Ceppi > Juju Developer Experience group > > [0] http://pythonwheels.com/ > [1] https://github.com/cloudbase/juju-powershell-modules > [2] https://crates.io/crates/juju > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
