Experimental Python interpreter snap
James Henstridge
james.henstridge at canonical.com
Thu Feb 23 07:45:10 UTC 2017
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.
More information about the Snapcraft
mailing list