On 23 February 2017 at 14:39, Stuart Bishop <stuart.bis...@canonical.com> wrote: > On 22 February 2017 at 21:47, James Henstridge <ja...@jamesh.id.au> wrote: > >> Yep. So I think it probably makes most sense for the Python runtime >> snap to default to classic confinement so that it behaves as a user >> would expect for interactive/development work, with pip ready to >> install to ~/.local/lib/..., or to the system wide $SNAP_DATA folder >> if the user really wants to install things system wide. This would >> seem to satisfy both use cases well. > > If $SNAP_USER_DATA/lib was used instead of ~/.local/lib for 'user' pip > package installs, then the snap python and the system python will > coexist better (as there is no risk of snap python finding a package > built by system python and vice versa). I have no idea if > sitecustomize.py could do this though, and suspect it might involve > patching. > > (do classic snaps actually have $SNAP_*DATA?)
So if I installed a package to $SNAP_USER_DATA for my "python36-jamesh.python3" interpreter, the files would end up somewhere under ~/snap/python36-jamesh/. If we then look at my simple hello-world example snap that uses the content interface to access the interpreter, $SNAP_USER_DATA now points to a location under ~/snap/hello-world/. So it wouldn't see the additional packages installed for "python36-jamesh.python3". In fact, the hello-world snap doesn't even have permission to read files under ~/snap/python36-jamesh, even if I put that directory on sys.path. Remember that the content interface is only sharing files: not any of the AppArmor permissions of the slot snap. James. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
