Import issues when running in an environment with multiple python interpreters
How to reproduce
Start container with controlled environment
# should work with docker as well, feel free to replace podman with it
podman run -ti --rm registry.nic.cz/knot/knot-resolver-manager/knot-manager:dev bash
inside the container, run
apt update
apt install -y debhelper dh-python
git clone https://gitlab.nic.cz/knot/knot-resolver-manager.git
cd knot-resolver-manager
pip install setuptools # this does nothing, just prints out that setuptools are already installed
pip install -U apkg # make sure we have the latest and greatest apkg :)
export CI=true # hacky way to bypass sanity checks in build script
apkg build
Observed behavior
dpkg-buildpackage: info: host architecture amd64
dpkg-source --before-build .
debian/rules clean
dh clean --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py clean
Traceback (most recent call last):
File "setup.py", line 2, in <module>
from setuptools import setup
ModuleNotFoundError: No module named 'setuptools'
E: pybuild pybuild:341: clean: plugin distutils failed with: exit code=1: python3.7 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.7 returned exit code 13
make: *** [debian/rules:4: clean] Error 25
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2
E command failed: dpkg-buildpackage -us -uc
Expected behavior
As setuptools
were installed, this error should not have occurred.
Why is this happening
setuptools
were installed for python 3.6. On the system in the container, python 3.6 is aliased globally as python
and python3
. However, python3.7
binary also exists and apkg
somehow invokes this version instead. The package setuptools
is installed only for python3.6
, not for python3.7
.
I am worried that this error is not caused by apkg
directly and that fixing it is not possible. Maybe, the dpkg-buildpackage -us -uc
command uses python3.7 explicitly and there is nothing we can do about it.
If the problem is only during build, than I can make some workaround. However, if the package ends up being targeted for python3.7
when I wanted to target python3.6
, that's bad.
I am happy to discuss this further personally...
EDIT:
In an environment with only a single python executable, it works properly. Can be tested in container registry.nic.cz/knot/knot-resolver-manager/knot-manager:debian
.