Experimental Python interpreter snap

[James Henstridge]

On 21 February 2017 at 20:53, Stuart Bishop <stuart.bishop at canonical.com> wrote:
> On 21 February 2017 at 18:35, James Henstridge
> <james.henstridge at canonical.com> wrote:
>
>>> You could probably also get the pip in your snap to install packages
>>> to $SNAP_USER_DATA or $SNAP_DATA if run as root. Although most devs
>>> would stick to using virtualenvs outside of the snap for this,
>>> assuming a modern enough Python.
>>
>> With the snap as it stands, it is most useful as a runtime for other
>> snaps rather than for interactive use or for development.  If you
>> install my package with --devmode to disable confinement, it could be
>> useful for development, but there isn't really an opportunity for a
>> shared site-packages directory ($SNAP_DATA for the python snap won't
>> be accessible to other snaps).
>
> I think I was thinking that the main snap could use classic
> confinement, allowing you to use it as the interpreter for scripts
> located anywhere. And snaps using the interface would remain contained
> as they are. Assuming we are allowed to mix interfaces and classic
> confinement :)

As I understand it, this should be fine: when you connect two snaps
with the content interface, all it does is bind mounts a directory
from the slot-side snap to a mount point within the plug-side snap.
It shouldn't matter what confinement policies the two snaps are using.
And since the snap data is a read-only squashfs, neither side can
alter the content that is being shared.


> But now I think on it further, its probably not a good idea to pollute
> the main python snap when it is being used as a dependency.

Well, it should be pretty easy to detect whether we're running in the
context of the Python snap: checking if sys.prefix is equal to $SNAP
would probably be enough (from a different snap, the interpreter will
be mounted somewhere else).  It wouldn't be difficult to add extra
directories to sys.path in this case, and with confinement disabled I
suspect we'd pick up the standard "user site" directory automatically.

So we might be able to do a single package that can both serve as a
runtime for other snaps and as a useful Python development
environment.

James.