<div dir="ltr">On 9 August 2016 at 19:08, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I personally like the idea that the snap could use a juju-home interface to<br>
allow access to the standard ~/.local/share/juju directory; thus allowing a snap<br>
and regular Juju to be used interchangeably (at least initially). This will<br>
allow thw use case "hey, try my juju snap and you can use your existing<br>
settings" But, isn't it verboten for snaps to access dot directories in user<br>
home in any way, regardless of what any interface says? We could provide an<br>
import tool to copy from ~/.local/share/juju to ~/snap/blah...<br>
<br>
But in the other case, using a personal snap and sharing settings with the<br>
official Juju snap - do we know what the official snappy story is around this<br>
scenario? I can't imagine this is the first time it's come up?<br></blockquote><div><br><br></div><div class="h5">The big difference to me is that $SNAP_USER_DATA will roll back if the snap is rolled back. I'm not sure what happens if the snap is removed and reinstalled. Given end users should no longer need to be messing around with the dotfiles, I think the rollback behaviour is what should drive your decision. Is it nice behaviour? Or will it mess things up because rollback will cause things to get out of sync with the deployments?<br clear="all"></div></div><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Stuart Bishop <<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></div>
</div></div>