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
