It sounds like the design goal for this is around "branches" of snaps, where you are essentially forking the version history, but 2 snaps are still considered the same identity, and thus sharing the same configuration. It also sounds like while that is a known and planned feature, it is not a high priority feature.
Is there a suggested work around for this in the short/mid term? John =:-> On Tue, Aug 9, 2016 at 4:37 PM, John Meinel <j...@arbash-meinel.com> wrote: > One thing that has come up in recent conversations is that while it is > great that I can push up a custom build of an official snap and have > someone just try it, none of their settings will come across. > > The specific case is for us developing Juju, where Juju will go out and > create new machines in AWS for you, and then tracks them currently in > ~/.local/share/juju/*.yaml files. I we wanted to move those files into the > SNAP_USER_DATA, then when I try to install a developer's version of Juju, > none of my controllers would be visible. (And even if we had a mechanism to > copy the data over, the data no longer stays in sync if I created/removed > entities in juju-jameinel.juju testing.) > > AIUI there is an interface for $HOME, but that doesn't expose any dot > files. Is there something around "I am an application of this <type> and > I'd like access to all of the data for <type>" that doesn't require > creating an new interface for every application? > > (As another example, imagine someone did a custom build of Firefox, > wouldn't you expect to still see all of your bookmarks?) > > John > =:-> > >
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
