Sharing "$HOME/.foo" between developer builds

[John Meinel]

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 <john at 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
> =:->
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160811/93032f87/attachment.html>