Description of the problem / feature request:
Consider a Starlark-generated executable target, which depends at runtime on a py_binary by placing it in its data attr, and which locates the path to that py_binary using a runfiles library that uses runfiles_manifest files.
In this scenario, the target will execute the py_binary using the "real" path of the binary inside bazel-bin, not a path relative to the original target's runfiles.
Bazel doesn't necessarily build the py_binary's own runfiles tree, so the python stub, which only looks at its own sys.argv[0], can't find its module space.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Expand Python-binary-failure-example.zip then run bazel run //:exe
What operating system are you running Bazel on?
macosx
What's the output of bazel info release?
release 3.4.1
Description of the problem / feature request:
Consider a Starlark-generated executable target, which depends at runtime on a py_binary by placing it in its data attr, and which locates the path to that py_binary using a runfiles library that uses runfiles_manifest files.
In this scenario, the target will execute the py_binary using the "real" path of the binary inside
bazel-bin, not a path relative to the original target's runfiles.Bazel doesn't necessarily build the py_binary's own runfiles tree, so the python stub, which only looks at its own
sys.argv[0], can't find its module space.Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Expand Python-binary-failure-example.zip then run
bazel run //:exeWhat operating system are you running Bazel on?
macosx
What's the output of
bazel info release?release 3.4.1