Call for testing: Python snaps

I posted about these snaps a while back on the mailing list, but thought I’d see if I could get some more exposure on this forum.

I’ve put together some snaps of the Python language runtime intended to be useful as both an ad-hoc interpreter and as a runtime for other snaps. You can install it with the following command:

snap install --edge --classic python36-jamesh

This will install the package using classic confinement, which is probably what you expect if you plan to use it interactively. If you’re only using it as a runtime for other snaps, you can install it without --classic. You can run the interpreter as python36-jamesh.python3, or add an alias for the more common name:

snap alias python36-jamesh python3

or if you have other versions of Python 3 on the system, perhaps:

snap alias python36-jamesh python3.6

The package comes with pip3 (which can also be aliased to the common short name), which can install additional packages if invoked with the --user option. The packages will end up installed in ~/snap/python36-jamesh/common/.

As mentioned earlier, the package is designed so it can share the Python runtime to other snaps via the content interface, so they don’t have to ship their own copy of the runtime. Here is a sample snapcraft project that demonstrates this here:

Once the package is installed, it will be necessary to connect the runtime:

snap connect hello-world:python3 python36-jamesh:python3

This will cause the runtime to be bind mounted into the application’s $SNAP directory, allowing it to find the interpreter. Note that it will only see the standard library: anything extra installed via pip3 won’t be visible. This is similar to the isolation you get using virtualenv.

Python 2 snap
Since the Python 3.6 snap seems to be working out okay, I adapted the packaging to produce a second snap of Python 2.7. It can be installed with:

snap install --edge --classic python2-jamesh

It supports all the same features as the 3.6 snap (aliases, content sharing to other snaps, etc), but I haven’t done as much testing on it.

I welcome feedback about either of these packages.


Just played a bit with it, I’m quite impressed. Also the snapcraft.yaml pretty nice!

What do you see the use-case for this Snap being? Presumably if people are installing Python programs we’d want them to just be able to install the program from the Software Center? :slight_smile:

Edit: Should’ve read the thing, interpreter and ad-hoc runtime, fair enough

Used as a runtime, the biggest benefit is to amortise the cost of the interpreter (both size on disk and in memory) between a number of applications. On the desktop, this would mainly result in smaller downloads for dependent applications. For smaller embedded devices, it might make using Python an option where it otherwise wouldn’t be.

With the trivial hello-world example I linked above, the resulting snap is only 4 kilobytes (which I guess is as small as squashfs file systems get).

It does have the downside of having to manually connect up the interface after installing the package, but presumably this is something that could be solved (it’s the same type of problem as for snaps using ubuntu-app-platform).

Ah that sounds good, yeah it needs to be made automatic, but this is good because I guess it still allows devs to bundle their own Python dependency if they need to, so we’re still avoiding potential dependency hell/bugs?

This can be done via snap declarations. The idea is, if there is an officially supported python snap, we can add a snap declaration so anyone plugging the content interface for the snap has it auto-connected upon install. ubuntu-app-platform has such a snap declaration already. People wanting to have such a snap declaration added to their snap should use the store category of this forum for the request.

I’m not sure my packages are ready for that yet. I haven’t even promoted them from the edge channel yet, and would prefer to see a bit more use first.

Thanks for your tips Jamie.
I did a little investigation and learned what the snap-declaration is. But I’m a little bit confused before that it seems to me the documentation doesn’t indicate the way to apply and request to have such a snap declaration added to a snap.

It’s clear to me now.

Im getting an error about plugs and slots with the latest Core 16 image.

#snap install --edge python36-jamesh
2017-05-27T13:54:01Z INFO snap “python36-jamesh” has bad plugs or slots: python3.6 (invalid interface name: “python3.6”)
python36-jamesh (edge) 3.6.1 from ‘jamesh’ installed

name -a
Linux localhost.localdomain 4.4.0-1051-raspi2 #58-Ubuntu SMP Fri Mar 24 13:48:21 UTC 2017 armv7l armv7l armv7l GNU/Linux

It doesn’t look to have installed successfully as a result (no python36-jamesh exists). and the suggested alias command fails:

snap alias python36-jamesh python3
error: cannot perform the following tasks:

  • Setup manual alias “python3” => “python36-jamesh” for snap “python36-jamesh” (cannot enable alias “python3” for “python36-jamesh”, target application “python36-jamesh” does not exist)

This looks harmless, but I’ll need to roll a new snap that changes the interface slot name.

This is due to a change in the syntax of the snap alias command since I first posted about this package. I think the equivalent syntax now would be:

snap alias python36-jamesh.python3 python3

The big advantage to me is that snaps do not need to be rebuilt and republished to get the latest point release of Python.

This snap is not in the store. When will be release it?

The snap is currently only published in the edge channel. That means it doesn’t currently show up with snap find. You should still be able to install it using the commands given.

I’ve also gone through and updated the packages to 3.6.4 and 2.7.14, so they’re both up to date again. As before, the package is available on amd64, i386, arm64, and armhf.

is there some plan to do this application stable in the futuro?

Enviado desde ProtonMail móvil

On 24 de enero de 2018 12:20 a.m., James Henstridge escribió:

Is there some plan to become this application stable in the futuro. I mean Channel stable.?

This is brilliant! I’m exploring this kind of architecture for ARM targets where cross compilation isn’t practical and native snap build times are excessively long.