VCS code duplication and subordinate

[Clint Byrum]

Excerpts from Sidnei da Silva's message of 2013-03-11 13:02:13 -0700:
> On Mon, Mar 11, 2013 at 4:49 PM, Clint Byrum <clint at ubuntu.com> wrote:
> 
> > Excerpts from Sidnei da Silva's message of 2013-03-11 11:14:52 -0700:
> > > On Mon, Mar 11, 2013 at 3:01 PM, Patrick Hetu <patrick.hetu at gmail.com
> > >wrote:
> > >
> > > > > Sure, but how will it make sure that the service is restarted when
> > new
> > > > content is found?
> > > >
> > > > In the python-django charm I'm using a timestamp variable (an idea
> > > > from someone on IRC) that triggers the reloading of the wsgi server
> > > > when configuration change.
> > > >
> > > > See:
> > > >
> > http://bazaar.launchpad.net/~charmers/charms/precise/python-django/trunk/view/head:/hooks/config-changed#L133
> > > >
> > > > > It's also possible to add this to a standard library of charm tools,
> > > > rather than do it in a subordinate.
> > > >
> > > > I was thinking about one subordinate charm per vcs because I didn't
> > > > wanted to install all vcs
> > > > when I'm just using one of them. But that's a minor issue.
> > > >
> > > > > This might be a good time to mention there's a VCS Charm Helper
> > > >
> > > > Yeah, extending and using those helpers would the solve the
> > > > dependencies problem.
> > > >
> > > > I'm also copying those helpers too in all my new charms to avoid
> > repetition
> > > > and I just realized they are pretty much all in charm-tools. Maybe we
> > > > could split
> > > > the python version of those helpers in a python-charm-tools package an
> > > > make them importable
> > > > python code?
> > > >
> > > >
> > > >
> > http://bazaar.launchpad.net/~charmers/charms/precise/postgresql/trunk/view/head:/hooks/hooks.py
> > > >  (first half of the file)
> > > >
> > > >
> > http://bazaar.launchpad.net/~charmers/charms/precise/postgresql/trunk/view/head:/hooks/helpers.py
> > > >
> > > > Patrick
> > > >
> > >
> > > That would be really helpful. We're collecting some things over at
> > > https://code.launchpad.net/~charmsupport/charmsupport/trunk but it's
> > > currently a chicken-and-egg problem because you need to have charmsupport
> > > installed before it can be used, so as a short-term measure we included a
> > > copy of it when deploying a charm.
> > >
> >
> > This stuff should be in the python charm-helpers. Its already setup to
> > be an importable python library and its quite easy to add via the PPA
> > to any charm.
> >
> > Also, the install hook is for bootstrapping things so that the other
> > hooks can respond to orchestration events. So put uncomplicated straight
> > forward commands to apt-get/pip install in the install hook, and then
> > write the other hooks (like config-changed) with these helpers.
> >
> 
> There was some discussion about this at some point, but IIRC the conclusion
> was that charm-helpers should be only for very low-level helpers, and not
> things like relation_get()/relation_set() helper functions. If there was
> some misunderstanding I'm more than happy to push for those helpers to land
> into charm-helpers.
> 

I don't recall the discussion, and I've not been party to more recent
discussions.

The original idea was that charm-tools and charm helper would be for
anything that we see getting copy/pasted/mimiced between multiple charms.