apt layer should use lib/charms/layer structure

[Adam Stokes]

The majority of bigdata layers and others use the directory structure of lib/charms/layer/apt.py. I think this should also conform to that layout as to keep usage of layers consistent

[Stuart Bishop (stub)]

I can put in aliases, but it is too late to move from charms.apt. It is unfortunate that other layers chose a different layout, and are squatting in a directory controlled by the base layer for layer options.

[Cory Johns (johnsca)]

The convention that I've been using and recommending is that charms.X is a namespace for general libraries related to charming, with examples being charms.reactive, charms.templating.jinja2, etc, and charms.layer.X is a sub-namespace for code provided by, or used by, a specific layer, with the convention there to use the layer name, as in charms.layer.<layer_name>. The charms.layer.options package breaks this convention, since it is generally useful across layers, and it should probably be broken out into a separate package and renamed to charms.layer_options, or similar.

I thought this convention had been discussed on the Juju mailing list, but I can't find any post about it so apparently not.

[Stuart Bishop (stub)]

My newer layer's are following the charms.layer.<layer_name> convention. Its just the apt, leadership and coordinator layers that are the problem because they existed before this convention and need to remain backwards compatible (at least for a while - we can deprecate the aliases and remove then after a few months).