Apt layer released

[Stuart Bishop]

On 28 January 2016 at 23:01, Adam Stokes <adam.stokes at canonical.com> wrote:
> Why would someone want to use this instead of what's provided in
> charmhelpers?

This wraps what is provided in charmhelpers.

To use raw charmhelpers, you need to write the hooks and handlers to
call its features at the right time and in the right order. You need
to call fetch.configure_sources, whenever the relevant config items
change. You need to install the list of extra packages, whenever the
relevant config item changes. You need to repin held packages, if the
option is set, whenever new packages are installed. To use the layer,
you just add an entry to layers.yaml and get it all done for you, and
it is all done consistently across all charms using the layer. You
don't have to worry about inconsistencies between your
reimplementation of the wheel with the next charms reimplementation of
the wheel causing confusion to users.

It also removes all the boilerplate. You don't need to include all
that gumph in your config.yaml.

It sets reactive states your handlers can wait on so you don't have to
set reactive states your handlers can wait on.

By requesting a package install and having handlers wait on the
install to complete, you get to write highly decoupled code without
losing efficiency. Several different handlers in different parts of
the code base and even in different layers can all schedule the
packages they care about to be installed, and have a single apt-get
update run, and only if necessary.

Improvements to the layer improve all charms using the layer. When
Juju charm configuration gets richer data structures, we can write all
the migration, compatibility and deprecation stuff once and all charms
get it next time they are built. Fixes in the charmhelpers codebase
can't fix its callsites or improve the documentation in your
config.yaml.

So you want to use it to save initial work and future maintenance :)



-- 
Stuart Bishop <stuart.bishop at canonical.com>