/usr/bin/env: ‘python3’: No such file or directory when running in docker

[ibolit]

I am trying to run my build on CI, where it is executed in a docker container with very little installed in it. To make matters simpler, I wrote a python file that prints out the current python version.

I followed the instructions on registering the toolchain from the README in this repository, and it works great on my local Mac. To make sure that I am using the python from the hermetic toolchain, I changed the python_version in my WORKSPACE.bazel file, and my simple programme did indeed start printing out that new version.

However, when I run it in the container that will be used on CI, I get the /usr/bin/env: ‘python3’: No such file or directory error.

At some point I installed Emacs in that container to be able to edit files, and the build magically started working. Turns out, Emacs installs a version of python. The weird bit is that the python version printed out by my programme is the one that is set in the WORKSPACE.bazel file and does change when I change the python_version in workspace.

Is this a bug in python_rules or do I have to add something to my WORKSPACE.bazel or install into my Docker container?

[ibolit]

I could replicate this behaviour by installing just python in my empty docker container:

1. Run bazel run //my_simple_programme:version in the empty container. Get the /usr/bin/env python3 error
2. Install python (apt install python3), the version installed ends up being 3.10
3. Run bazel run //my_simple_programme:version, the result is sys.version_info(major=3, minor=11, micro=1, releaselevel='final', serial=0), as specified in the WORKSPACE. I will try and create a minimal dockerfile and bazel project to replicate that.

[ibolit]

Sorry, after more careful scrutiny of the readme, I saw this:

After registration, your Python targets will use the toolchain's interpreter during execution, but a system-installed interpreter is still used to 'bootstrap' Python targets (see #691).

I am closing this ticket