Do we need charm "snippets"?
juan.negron at canonical.com
Wed Nov 23 00:16:55 UTC 2011
We could have a separate package for it. I don't think we should force it
upon people just "srtongly suggest it" :)
On Tue, Nov 22, 2011 at 4:04 PM, Marco Ceppi <marco.ceppi at seacrow.org>wrote:
> I think this is a good idea for a star. One question I have, how would
> charms 'get' the charms-helper package to start? A bzr branch in the
> installer, something in the meta.yaml file?Or would this be included in the
> cham-tools package?
> Marco Ceppi
> Sent while mobile
> On Nov 22, 2011 6:57 PM, Juan Negron <negronjl at xtremeghost.com> wrote:
> +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.
> 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:
>> > 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:
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Juju