<div dir="ltr">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.<div><br></div><div>Is there a suggested work around for this in the short/mid term?</div><div><br></div><div>John</div><div>=:-></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 9, 2016 at 4:37 PM, John Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.)</div><div><br></div><div>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?</div><div><br></div><div>(As another example, imagine someone did a custom build of Firefox, wouldn't you expect to still see all of your bookmarks?)</div><div><br></div><div>John</div><div>=:-></div><div><br></div></div>
</blockquote></div><br></div>