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
The venv is recreated whenever the binary is executed. This prevents packaging up the binary and installing it to a system outside of bazel as an application deployment that can be run by other users from a common directory e.g. an /apps directory, possibly served read-only over nfs or similar.
Describe the feature
I would like either for the venv creation to fallback to a user writable location e.g. XDG_CACHE or to remove the need to recreate the venv links so it can be done once by an admin user and then subsequent users can just execute from the precreated venv.
The text was updated successfully, but these errors were encountered:
Another place where this could be used is in an immutable container - the container is built and then at execution time the container image is made immutable and so writing to the runfiles directory would potentially not be possible in this case too.
Also the current behaviour would prevent multiple copies of a binary running at the same time since it would delete files being used by the first process on the execution of the second process.
We've run into this issue with when running py_binary targets from this ruleset in an immutable environment. One example is when running code in a os-only aws lambda runtime, the lambda is unpacked in an immutable env and the py_binary fails to run.
What is the current behavior?
The venv is recreated whenever the binary is executed. This prevents packaging up the binary and installing it to a system outside of bazel as an application deployment that can be run by other users from a common directory e.g. an /apps directory, possibly served read-only over nfs or similar.
Describe the feature
I would like either for the venv creation to fallback to a user writable location e.g. XDG_CACHE or to remove the need to recreate the venv links so it can be done once by an admin user and then subsequent users can just execute from the precreated venv.
The text was updated successfully, but these errors were encountered: