Charm derivation

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of Mon Jan 16 13:49:39 -0800 2012:
> Then, refactor it out
> > That's exactly what I'm asking about, how should I go about doing this?
> 
> I'd start by registering juju-django in Launchpad and pulling the
> logic from Michael's charm onto a branch and tweaking it to work like
> a library with established conventions for how to use it. Then, on
> your charm, tweak the install hook to pull the branch and install the
> desired hooks, and follow the established conventions. We can evolve
> from there and see what lessons we learn and which needs come up.
> 

It might make sense to fold this work into charm-tools as a django
helper. We've found that there are a lot of super-generic things that
need to be done in multiple charms, like download a file and verify its
hash, or elect a leader of a peer relation. As Gustavo suggested, some of
this will ultimately be better served in juju core, but while its not,
a set of helper scripts allows rapid development, and when it gets into
juju core, we can simplify the helpers to call those parts of juju.

Basically you'd want to move any python or shell that is generic to all
django charms into lp:charm-tools/helpers/(pp|py|sh)/django.(pp|py|sh)
and then make calls out to the code in it. The generic django charm
would work for deploying only the most basic django app (one that uses
one database and runs via mod_wsgi for instance). As long as the hooks
are reduced down to a few calls to the django charm helper then cargo
culting doesn't hurt so much, because you're still making use of the
shared code in charm-helpers.  And if you come up with a good generic
way to configure other common interfaces, then you could add those to
the charm helpers as well.

Once it is in charm-tools as a helper, it will be built as a binary
package that will even depend on the version of django it is written
for, so one need only add the charmers charm-helpers PPA, install the
charm-helpers-django package, and then start making use of the shared
code.

I see charms more like data models, which don't necessarily map well
to the concept of inheritance. In my experience, data models sometimes
make more sense as basic objects with generic programming used for the
algorithms that act upon a similar set of objects.