[FR]: Support for shell-less environments

[jorgedomingomasmovil]

What happened?

Hello,

I have another issue related to this problem open in rules_oci.

Basically I am using the example provided by rules_oci to generate a python image with a distroless as base image. The problem is that the file generated with the py_binary rule from aspect_rules_py generates a script to run with bash, it executes an exec on the last line

exec "{{EXEC_PYTHON_BIN}}" {{INTERPRETER_FLAGS}} "$(rlocation {{ENTRYPOINT}})" "$@"

and distroless do not have bash to be able to run that script to execute the python binary so I get the error of:

exec /oci_python_image/hello_world/hello_world: no such file or directory

The solution proposed in the other issue I have open works but it involves using the py_binary rule of another dependency, I would like to know if there is any way to use the py_binary from aspect_rules_py with distroless or is it going to be implemented?

Thanks in advance

Version

Development (host) and target OS/architectures: host is Mac and target is debian 12.9 (python distroless from google)

Output of bazel --version:
bazel 7.4.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:
bazel_dep(name = "aspect_rules_py", version = "1.3.1")

Language(s) and/or frameworks involved: python and py_binary from aspect_rules_p

How to reproduce

Using the example provided by rules_oci (https://github.com/aspect-build/bazel-examples/blob/main/oci_python_image/hello_world/BUILD.bazel) but using a distroless as base image

Any other information?

No response

[arrdem]

The basic problem is this; something which can interact with Bazel's runfiles is needed to chainload an interpreter out of your runfiles and provide it the location of your entrypoint script.

A PEX or other zipapp sidesteps this problem, but does so by being a self-extracting executable which requires an external interpreter on the host. Often zipapps will use shells for this, although some format such as sci-e use native binaries.

rules_python manages this either (historically) by using a bootstrap interpreter on the host as you noted in the rules_oci exchange or more recently using a shell because shells are universally available in anything other than distroless containers.

aspect_rules_py faces the same challenge and likewise concludes that the most portable option other than using a native code launcher is to use a shell.

There's some discussion of this concept here bazel-contrib/rules_python#2500 and bazelbuild/proposals#275. There's another related thread on the rules_python tracker I'm not finding right off.

---

With the arrival of the py_venv_binary and especially #629, we're actually fairly close to this since the "interpreter" in a prebaked venv/binary is now usable without any specific setup. But something still needs to find the rlocation of the venv's "interpreter" shim and execute it, and because venvs are TreeArtifacts Bazel itself can't refer to stuff inside of the venv.

From a custom oci_image you could certainly manually set the entrypoint path to be where the venv's interpreter lands and provide it with the path of your entrypoint file as argv and get the desired behavior. But we don't yet have a way to wrap that up into something that "just works" because we need a declared output file Bazel knows about which can be the entrypoint and which lives outside of the TreeArtifact containing the venv.

For that yet another shim binary tool would be required.

[arrdem]

We took a crack at this in #825 and it didn't work out, see #849. I'd love to get that re-landed but we'll need either a custom shim or to get changes in to Malte.

[jbedard]

py_binary no longer uses any shell/bash but hermetic-launcher instead so I believe the primary issue here is solved?