google / subpar

Subpar is a utility for creating self-contained python executables. It is designed to work well with Bazel.
Apache License 2.0
567 stars 69 forks source link

Boilerplate shebang question #90

Closed groodt closed 5 years ago

groodt commented 5 years ago

I've come to realise that the Bazel Python support is not hermetic and that there is lots of work happening around py_runtime and py_toolchain to possibly address some of the issues.

One thing that I've noticed with subpar specifically, is the code that generates the boilerplate shebang line in the .par executable file, is obtained by sniffing the PYTHON_BINARY from the stub_file.

The implications of this for me, are that the target runtime environment will need to have the python interpreter installed at the same location as the environment used to build the subpar archive.

This is currently causing me some problems, because I'm trying to use Nix to setup a hermetic build environment. The regular build and test is working reliably on Nix for developers and CI machines, but unfortunately, the .par files that are generated are not portable. This is because the location of the Python3 interpreter within Nix becomes something like: /nix/store/qbp8hp47y9xbk7065q9rkzhfbwaym6cy-python3-3.7.0/bin/python3 and the subpar shebang then becomes: #!/nix/store/qbp8hp47y9xbk7065q9rkzhfbwaym6cy-python3-3.7.0/bin/python3

When this is then bundled into a distroless or alpine Python3 Docker container, the subpar file cannot be executed, because the Python interpreter is not located in the same location.

Now, I guess that I could make the target runtime environment skip the shebang line by invoking it like python3 file.par.

I'm just wondering if this is the best way to be doing things, or if there should be an additional way of setting the interpreter in the shebang.