I'm not sure I understand the problems this is solving that aren't adequately solved by branching from a source charm. It seems like the hard part of branching - maintaining changes to non-trivial code - is not helped by this tool. For charms that just need to add hook files or modify charm metadata, this seems fine, but those don't seem like the difficult parts of branching from a source charm either. I guess my point is, this seems like it's doing a lot of what version control already does.
On Fri, Jul 10, 2015 at 2:22 PM Benjamin Saller < benjamin.sal...@canonical.com> wrote: > Charm Composition is a small tool facilitating a new pattern for > developing and maintain Juju Charms. In its simplest form it lets you > combine directories, called Layers, of files to create a charm. Rather than > just copying files around however it keeps track of which files came from > which Layer so that at a later time the process can be run again. This > means that if any of the Layers have changed those bits will be reflected > in the newly regenerated charm. > > Imaging that you have a charm you’ve forked to add some simple tweak or > customization. You might be able to maintain your changes in a new Layer > allowing the base you depend on to continue to evolve. > > Suppose we have layer ‘a’. > > trusty/a/ > > ├── hooks/install > > ├── metadata.yaml > > └── README.md > > And a layer ‘b’ > > trusty/b/ > > ├── hooks/db-relation-changed > > ├── composer.yaml > > ├── metadata.yaml > > └── README.md > > If ‘b’ included ‘a’ (specified in the composer.yaml file) then composer > might combine the layers in the following way. > > trusty/b/ > > ├── hooks/install > > ├── hooks/db-relation-changed > > ├── composer.yaml > > ├── metadata.yaml > > └── README.md > > That is just a ‘cp -r’ you’re saying, and it would be except the compose > process is able to support a variety of methods for combining layers. By > default compose knows about Charm specific files like metadata.yaml and > config.yaml it is able to combine them in sensible ways. For files like > this the default is a merge with the ability to remove add/replace keys > within the data of the file in the lower layer (in this case ‘a’ would be > overridden if it had a key in common with ‘b’ when composed). > > Composer itself is extensible so if you’re layers need special rules > associated with how certain types of files should be combined there is an > interface for doing that. > > Composer has code for doing much more interesting things than just > combining layers, but we can save that for another post. If you’re > interested in this now and want to start thinking about what nice base > layers might look like, check it out at > https://github.com/bcsaller/juju-compose > > > > Thanks, > Ben > > There is more that should be said about how this relates to the work with > Relation Stubs and so on but that can be another thread. > -- > 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
