feat(rules): add PyExecutableInfo#2166
Conversation
744da90 to
1b37eea
Compare
The PyExecutableInfo provider exposes executable-specific information that isn't easily accessible outside the target. The main purpose of this provider is to facilitate packaging a binary or deriving a new binary based upon the original. Within rules_python, this will be used to pull the zip-building logic out of executables and into separate rules.
1b37eea to
c6df780
Compare
|
Just brainstorming here. This might be also beneficial for rules_oci users who would like to create a tarball with a different layout of the files. I think in a similar fashion we could also list sources for each third party package so that users can also do whatever they want with that. Having some sort of depset map could be useful. That way people would not need to rely on site-packages string being in the path and we could also have a venv building rule. |
…o feat.pybininfo
|
Yes, packaging a py_binary into a tar is the sort of use case I have in mind. That's not much different that a zip file, really. rules_oci + reorganizing site-packages gives me another use case idea: packaging multiple binaries into an image and reducing duplication. So don't include the python runtime in |
PyExecutableInfo was added in #2166 with the field `runfiles_without_exe` that intentionally excludes unrelated files. But, within Google we found that we need to pick up the file with build stamp information at that stage as well, so it is being additionally exposed.
PyExecutableInfo was added in #2166 with the field `runfiles_without_exe` that intentionally excludes files that are specific to that target/executable, such as the build data file (which may contain the target name, or other target-specific information). However, consuming tools (such as ones used within Google) may need to derive a file from that build data, override it completely, or be happy with its content as is. To aid that case, expose it via PyExecutableInfo.
The PyExecutableInfo provider exposes executable-specific information that isn't easily accessible outside the target. The main purpose of this provider is to facilitate packaging a binary or deriving a new binary based upon the original.
Within rules_python, this will be used to pull the zip-building logic out of executables and into separate rules. Within Google, this will be used for a similar "package a binary" tool.
Along the way: