-
-
Notifications
You must be signed in to change notification settings - Fork 678
per-binary opt-in of pyc doesn't function correctly #2212
Description
🐞 bug report
Affected Rule
py_binary/py_test
Description
The intent of the py_binary.pyc_collection attribute is to allow per-target opt-in for using pyc files from dependencies without specifying command line build flags. This allows for a couple use cases:
- Build tools can have precompiling enabled (separate from the requested target)
- Gradual enabling of precompiling can be done (on a per-target basis) without having to figure out where and how a user is setting build flags (which isn't always possible, e.g. during the dev edit-run cycle).
Right now, what happens is, when py_binary.pyc_collection=include_pyc, pyc files from transitive targets are collected, but only if they opted into precompiling with their target-level precompile attribute. When the vast majority of targets don't set that, the net effect is no pyc files are collected. This happens because pyc file generation is conditional on the precompile settings, e.g. if its not enabled, no action generates the file.
To fix, the basic thing that needs to be done is always generate a pyc file and always include it PyInfo.pyc_files. Then, when the binary looks at the transitive pyc files, it'll find them all.
A caveat is: don't add the pyc files to runfiles unless the target opted into precompiling. Doing so would cause all downstream targets to have the pyc, as opposed to only the binaries that want it. It's OK to put the pyc in default outputs (the default outputs of deps aren't included).