Duplicated copy of Python available in core

For snaps that use the python plugin, I see that they include a copy of Python 3.5, but as far as I can tell, this is also in the core snap.

Why doesn’t snapcraft omit the copy of Python, since it should know that core has it?

In particular, I verified that the SHA-1 sum of the /usr/bin/python3.5 binary in core matches that in $MY_SNAP/usr/bin/python3.5

We discussed this at length and went back and forth on it. There are two problems today (which should be sorted along the way):

  • We would need core available to determine the interpreters are indeed the same.
  • We don’t want to tie snaps to the use of /snap/core/current/usr/bin/python3 if we don’t need to and wait out on /snap/<base>/current/usr/bin/python3.

From the top of my head, some technical hurdles we would need to sort out:

  • Use of python3- stage-packages will always bring in python.
  • Fixup our sitecustomize.
  • Find a way to override a dist-packages python package on core with one the developer would want (in the context of wanting latest) and preferring that version.

Why? AIUI snapcraft already excludes libraries that are in core which it identifies by name (could easily be hashsum). i.e. snapcraft could know the hashes of things in core and automatically exclude them from the generated snap.

When bases come along, I assume that the Ubuntu 16 base will include the same Python that’s currently in core? Given above, would snapcraft be happy to pull the base, but not core?


With updates of the base, the hashes change, we will need a nice way to determine that even if the hash is different the origin is the same. I would really like to tie this to some base work we have to do to determine intent.

Once the base work is in place we can determine intent easier and do the right thing. But the story will be vastly different for classic confinement given that we cannot patch the python interpreter in core/base and all the other libraries there in order to have a strict linker loader or rpaths to specific library paths (important for classic confinement to mix up with host ones), so we will need to bring in the interpreter regardless for certain scenarios mudding the plugin logic a bit.

Also, python3 will always be part of the 16 base, but it might not be in the 18 one (it is only there to support cloud-init).

1 Like