fix(py_binary): include runfiles.symlinks/root_symlinks in python_zip_file#3750
fix(py_binary): include runfiles.symlinks/root_symlinks in python_zip_file#3750TvdW wants to merge 1 commit intobazel-contrib:mainfrom
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request ensures that runfiles.symlinks and runfiles.root_symlinks are correctly included in the python_zip_file output group, which fixes issues with certain data dependencies (e.g., sh_binary under Bazel 9). The implementation updates the zip manifest generation logic and includes a new test suite to verify the contents of the generated zip. Feedback focuses on optimizing the collection of symlink target files by using depsets instead of list concatenation to improve efficiency.
…_file The legacy zipapp manifest builder only iterated `runfiles.files`, silently dropping any entries contributed via `ctx.runfiles(symlinks=...)` or `ctx.runfiles(root_symlinks=...)`. This surfaced under bazel 9 / rules_shell 0.6 because `@bazel_tools//tools/bash/runfiles:runfiles` became an alias whose legacy path is exposed via a root_symlink, so sh_binary deps of py_binary failed to bootstrap from the produced zip with "cannot find bazel_tools/tools/bash/runfiles/runfiles.bash".
|
We've deprecated the implicit zipapp support, so I don't think we'll fix this. The py_zipapp_binary rule that replace it fixes this |
|
That's fine, but this issue also affects |
3 participants
The legacy zipapp manifest builder only iterated
runfiles.files, silently dropping any entries contributed viactx.runfiles(symlinks=...)orctx.runfiles(root_symlinks=...). This surfaced under bazel 9 / rules_shell 0.6 because@bazel_tools//tools/bash/runfiles:runfilesbecame an alias whose legacy path is exposed via a root_symlink, so sh_binary deps of py_binary failed to bootstrap from the produced zip with "cannot find bazel_tools/tools/bash/runfiles/runfiles.bash".