Do we need charm "snippets"?
clint at ubuntu.com
Wed Nov 23 19:13:58 UTC 2011
Marco, very cool! Lets just fold this into charm-tools actually. I see
no reason to split the two efforts.
I think the structure would be something like:
Also for all the shell functions, since shell is a flat namespace,
they need a leading namespace, maybe chrm_?
Then we can just have charm-tools build these as packages, charm-helper-sh
and python-charmhelper (when that need arrises). Those packages will be
the ones that charms apt-get install when they need helpers.
(Btw, lets strive to keep it working in sh.. just for those like me that
appreciate the simplicity and speed of /bin/dash).
Also, please tack license headers onto the files. They're likely to get
copied around even though they're in packages, so lets make sure the
files are explicitly licensed.
Excerpts from Marco Ceppi's message of Wed Nov 23 09:52:16 -0800 2011:
> I created a few functions that I use in charms I've made/are working on and pushed them up to https://code.launchpad.net/~marcoceppi/charm/oneiric/charm-helper/trunk I couldn't think of a better place to put them repo wise and I figured might as well start a small collection while the medium is decided.
> Feedback or suggestions are welcome.
> Marco Ceppi
> >---- Original Message ----
> >From: James Westby <james.westby at canonical.com>
> >To: "Clint Byrum" <clint at ubuntu.com>, "juju" <juju at lists.ubuntu.com>
> >Sent: Tue, Nov 22, 2011, 23:00 PM
> >Subject: Re: Do we need charm "snippets"?
> >On Tue, 22 Nov 2011 13:49:41 -0800, Clint Byrum <clint at ubuntu.com> wrote:
> >> I think the best way to get this done is to add a bit of "Should" policy
> >> that states that code should not be copied from one charm to another,
> >> but instead should be added to charm-helper and removed from both charms.
> >I see this as somewhat similar to maintainer scripts in packaging
> >(e.g. http://wiki.debian.org/DpkgConffileHandling,) which has shown that
> > nothing < documentation of patterns < copied snippets < shared helper
> > library < built in
> >It's pretty easy to start moving up this chain and getting some
> >benefit. In fact it's the path that patterns/snippets take if they
> >remain useful and get adopted.
> >So +1 on doing something here, and +1 for doing it incrementally as
> >Clint suggests.
> >Also, keep an eye out for where something should move up a level, as
> >if the mass at one leve grows too large there will start to be problems
> >(e.g. having too many copied snippets can lead to it being hard to
> >change something in core juju as it would break too many charms.)
> >Juju mailing list
> >Juju at lists.ubuntu.com
> >Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
More information about the Juju