🚀 feature request
Relevant Rules
I want py_binary to return an additional provider, RunfilesGroupInfo.
py_library could contribute by also returning this provider, but that's more of an implementation detail.
I'd be open to work on this if you agree that this is a good idea.
Description
I'd like to make packaging of py_binary targets in container images more efficient. To that end, I have designed a set of providers and described their semantics in a new Bazel module.
Describe the solution you'd like
py_library targets should forward RunfilesGroupInfo and RunfilesGroupMetadataInfo from their deps and add their own runfiles (srcs, data) to a group.
py_binary targets should aggregate runfiles groups from their deps and emit RunfilesGroupInfo and RunfilesGroupMetadataInfo that contain at least:
- A group for the interpreter + standard library
- One group per third party dependency
Additionally, it could also make sense to produce groups for each py_library target in the transitive dependency graph.
Describe alternatives you've considered
Doing nothing would mean we continue creating (very large) container image layers that contain the full runfiles tree of a py_binary target.
Writing custom packaging rules just for rules_python is unsustainable in my opinion.
🚀 feature request
Relevant Rules
I want
py_binaryto return an additional provider,RunfilesGroupInfo.py_librarycould contribute by also returning this provider, but that's more of an implementation detail.I'd be open to work on this if you agree that this is a good idea.
Description
I'd like to make packaging of
py_binarytargets in container images more efficient. To that end, I have designed a set of providers and described their semantics in a new Bazel module.Describe the solution you'd like
py_librarytargets should forwardRunfilesGroupInfoandRunfilesGroupMetadataInfofrom their deps and add their own runfiles (srcs,data) to a group.py_binarytargets should aggregate runfiles groups from their deps and emitRunfilesGroupInfoandRunfilesGroupMetadataInfothat contain at least:Additionally, it could also make sense to produce groups for each
py_librarytarget in the transitive dependency graph.Describe alternatives you've considered
Doing nothing would mean we continue creating (very large) container image layers that contain the full runfiles tree of a
py_binarytarget.Writing custom packaging rules just for rules_python is unsustainable in my opinion.