Do we need charm "snippets"?

Juan Negron negronjl at xtremeghost.com
Tue Nov 22 23:57:34 UTC 2011


+1 on charm helper package.
Maybe the charmers can initially create such a tool and lead by example
modifying the "official" charms to use this tool.

As a by-product, the work done in the "official"charms charms can be
referenced as examples on how charms should be coded and organized.

Thanks,

Juan

Sent from my mobile.
Apologies for the brevity of this message.
On Nov 22, 2011 4:50 PM, "Clint Byrum" <clint at ubuntu.com> wrote:

> Excerpts from Jorge O. Castro's message of Tue Nov 22 13:14:41 -0800 2011:
> > Today Mark Mims and I were discussing how to help George sort out his
> > mail requirement for the thinkup charm:
> >
> > - https://bugs.launchpad.net/charm/+bug/891749
> >
> > Right now I am helping him find how to use debconf to just set up
> > postfix to send mail. It doesn't need to be a full charm, just a
> > "snippet" to do what it needs. But what about the next LAMP charm that
> > needs something similar?
> >
> > Similarly, Marco does a install_steam function here:
> >
> http://bazaar.launchpad.net/~marcoceppi/charm/oneiric/steam/trunk/view/head:/env/funcs
> >
> > that grabs an upstream binary but does sha1sum check for the binary.
> > If I were to make a similar charm I would really want to steal that
> > specific part. Ditto for things like "grab this specific thing from
> > github, but default to the packaged ubuntu version", and so on.
> >
>
> Agreed, this belongs in packaging. Anything that is shared amongst charms
> should go in packages. PPA is fine at first, but we should strive to
> get things into universe at the very least, and main when the charm is
> dealing entirely with software in main.
>
> > We already know that sharing charms is very useful and a great part
> > about juju. Should we be investigating documenting snippets of best
> > practices as well? Mark was thinking something along the lines of
> > libcharmtools-bash, libcharmtools-python, and so on.
>
> I think 'charm-helper' is a good idea for a name for a project to track
> these bits.
>
> 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.
>
> Eventually we can have juju automatically install charm helper and other
> packages based on clues in the metadata, much like debian source packages
> have a 'debian/source/format' and a 'debian/compat' that tell the tools
> how to build them.
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20111122/954887e8/attachment.html>


More information about the Juju mailing list