[Bug 1611287] Re: provide canonical way to install templates and configuration files into $SNAP_* dirs

[Nick Moffitt]

Whether it's hackish or not, it is a step we're taking to work around an
obstacle snappy throws up but provides no mechanisms to deal with.

I think we're all taking roughly the same approaches, and that's
encouraging that people are unlikely to get this wrong if we can't fix
it.  But it does make for a rather un-DRY experience that is a bit
jarring.

I would support adding some sort of mechanism to make these sorts of
operations first-class and consistent.

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to snappy in Ubuntu.
https://bugs.launchpad.net/bugs/1611287

Title:
  provide canonical way to install templates and configuration files
  into $SNAP_* dirs

Status in Snapcraft:
  New
Status in Snappy:
  New
Status in snappy package in Ubuntu:
  Confirmed

Bug description:
  We have had a ML discussion about it, but I think it is worth to track
  it properly:

  I was asking about the preferred way to handle conffiles and such.
  There seems to be some new functionality incoming, quoting from the ML:

  "> The only snap-centric artifact about it I found was [1]. But that feels
  > broken/outdated as there is no "snappy" command anymore (and snap has no
  > "config" subcommand).

  Something similar will come back. From what I've heard there will be a
  apply-config hook which you can implement in your snap and a user can
  call from the outside with a simple 'snap set
  snap.name.confkey=confvalue' or similar."

  But since it seems that for the former there is already work in progress (although I don't know the bug), there was something related brought up that is important just as well - and this is what this bug is about.
  Quoting Nick Moffit from the Mail:

  "Is there a good facility for install-time copying of template configs or
  other writeable-from-initial-state data into $SNAP_USER_DATA?

  The way snaps are invoked do a great job of hijacking the $*PATH
  variables used to find executables and shared objects, but often we need
  to hack in a lot of shuffling around for /usr/share and /etc and /var/
  to aim them at snappy's special directories."

  Currently I see myself and others implement something like "first call
  handlers" that copy content packaged in the snap (no reason to be
  there) to their intended place (user exposed configuration e.g. in
  $SNAP_DATA).

  I personally would think about something like:
  support for that in the copy plugin like supporting:
  parts:
   defaultconf:
     plugin: copy
     files:
         etc/example.conf: $SNAP_USER_DATA/etc/foo.conf

  Surely there is some more magic glue involved as at "snap building time" the path of $SNAP_USER_DATA and such isn't fix IIRC (could change per setup and in future).
  Therefore I'll file it for snapcraft & snappy right at the beginning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapcraft/+bug/1611287/+subscriptions