Experimental Python interpreter snap

[Spencer]

I thought a main feature of snaps was to include all dependencies so that they couldn't be changed out from underneath a package.  For example, my script was written for 3.6, but would be incompatible with a future release, say 4.0.

Still, the ability to share a dependency like the Python interpreter among python snaps may be a good idea if there are zillions of Python snaps.

At my work, we got tired of everyone maintaining their own local python installation, because we all ended up with slightly different versions of various python modules installed.  Worse, some modules installed for some while not for others.  So we started tracking a shared Python installation in git.  One problem we found is that Python is not relocatable.  This showed up when people cloned our repository in a different place.  Are you sure that your snapped Python is relocatable?  If so, I'd like to know how that works.  Is the $ORIGIN variable standard?


> On Feb 19, 2017, at 7:16 PM, James Henstridge <james.henstridge at canonical.com> wrote:
> 
> To learn a bit more about I put together a snap for Python 3.6.0,
> which can be installed with:
> 
>    snap install --edge python36-jamesh
> 
> You can then run "python36-jamesh.python3", which will give you the a
> Python shell running with strict confinement, with the full standard
> library available.
> 
> Now I know Snapcraft already has support for packaging Python
> applications, so what benefits does this package add?  There were a
> few extra points in how I built the package:
> 
> 1. the interpreter binary and extension modules all have appropriate
> $ORIGIN relative rpath set.
> 
> 2. a sitecustomize.py is provided that will add
> $SNAP/lib/python3.6/site-packages to sys.path. (more on why this is
> useful later)
> 
> This makes the interpreter fully relocatable in the file system while
> still being able to find the bundled libraries.  In turn, this means
> the interpreter is functional when exported to another snap via the
> content interface.
> 
> To demonstrate this, I put together a trivial "hello world" snapcraft
> project here:
> 
> https://github.com/jhenstridge/python-snap-pkg/tree/master/examples/hello-world
> 
> After building this package, it can be run after installing and
> connecting the interface:
> 
>    $ snap install --dangerous hello-world_0.1_amd64.snap
>    hello-world 0.1 installed
>    $ snap connect hello-world:python3 python36-jamesh:python3
>    $ hello-world
>    Hello world!
> 
> Since the hello-world snap doesn't actually include Python, it is
> quite light weight (4 kB, which I think is as small as a squashfs
> gets).  The space savings may not be that great with a single snap
> (the interpreter snap is almost 20MB), but the space savings increase
> as you install more snaps using the interface.  It also means that we
> could upgrade to Python 3.6.1 (when it comes out) without rebuilding
> this snap.
> 
> And since the interpreter is being run under the hello-world snap's
> confinement policy, it can do potentially do things the main
> "python36-jamesh.python3" binary can't.  For example, if you add the
> "network" plug, you'll be able to access the network.
> 
> And the sitecustomize script will also mean the interpreter can locate
> packages shipped in the plug snap.
> 
> I'd be interested in any suggestions or feedback about the snap.
> 
> Thanks,
> 
> James.
> 
> -- 
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft