Experimental Python interpreter snap

[James Henstridge]

On 23 February 2017 at 14:39, Stuart Bishop <stuart.bishop at canonical.com> wrote:
> On 22 February 2017 at 21:47, James Henstridge <james at 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.