The Snap I’m working with has a configure hook written in Python. It uses features available in Python 3.6 however our CI server is running Python 3.5.
Pyenv and similar tools are an obvious way of solving this however when the Snap is in classic mode, it always only uses Python installed at /usr/bin/python3 even when #!/usr/bin/env python3 is set in the configure hook.
I’ve confirmed that my user and the root user are setup to use the pyenv shim, however the Snap ignores it and uses the system’s version of Python.
Is this a bug or is this a known issue with a workaround? This issue forces us to modify our CI environment to upgrade the system version of Python which adds complexity to the process.
If still want to pursue the path you are in, you will probably have to set the appropriate paths at the environment level and not the login shell configuration, which is where I suspect you have your pyenv shim setup.
To be honest, I’m still a bit mystified why it doesn’t. For example, the Snap was upgraded to use core20 and now Python no longer works on Ubuntu 18.04. The Python script in question has the following shebang attached to it: #!/snap/slurm/current/venv/bin/python3 and that virtual environment is configured during the Snapcraft build.
for which you can bundle python in the snap
So to clarify, to effectively solve the problem in Classic mode, we will need to include the Python runtime as part of the Classic Snap? Can you help me understand why isn’t this the case for a Strict mode Snap?
A bit of background on the differences with classic:
A current workaround example:
With core20, by default the python binary is used from the base rather than adding it to the snap, which means snapcraft can’t patch it. The workaround is to force the staging of python3. We do want to address this issue, and I expect we will in the near future.
