You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to differences between the MacOS and Linux implementations of
Bazel's sandboxing (reported as #573) the current implementation of
manipulating `argv[0]` to make an interpreter see itself as having a
path of `.runfiles/.../.venv/bin/python3` isn't effective.
Specifically on Linux it appears that we're more eagerly resolving
symlinks.
This means that `bazel-bin/.../*.runfiles/*/.venv/bin/python3` is being
immediately resolved to an `/execroot/bazel-bin/...` entry which
_contains only generated files_. An interpreter with relative path based
import roots within the execroot will be able to import relocated
sources (copied into the venv) but will not be able to import from
source files or external generated files.
Effectively spawning the interpreter is escaping the `.runfiles` tree
which breaks a bunch of our other assumptions.
The repair is to come up with a more portable way to identify the
interpreter without escaping from the runfiles sandbox.
As a solution this PR makes the interpreter shim depend both on the
`$VIRTUAL_ENV` variable which also serves as an anchor to the "real"
`.runfiles` tree. Due to the removals of `realpath` calls in the
`activate` script, it's possible that we could provide fallback behavior
by introspecting `$0`, but that verges on #581 so punting for now.
---
### Changes are visible to end-users: no
### Test plan
- [x] Add imports from unmodified sources to the test cases
0 commit comments