Cleanup flags and code paths for legacy runtime resolution #8169
Labels
P3
We're not considering working on this, but happy to review a PR. (No assignee)
stale
Issues or PRs that are stale (no activity for 30 days)
team-Rules-Python
Native rules for Python
type: process
Comments
brandjon
added
P3
|
Any news? |
copybara-service bot
pushed a commit
that referenced
this issue
Feb 6, 2023
This fixes the failures on MacOS after the recent upgrade to CI. When `//src/test/py/baze:runfiles_test` sets `--incompatible_use_python_toolchains=false`, it eventuallys tries to search `PATH` for `python`. This is because it falls back to the `--python_path` flag, which has a computed default of "python". Since new Mac versions no longer provide Python 2, this doesn't work. To fix, enable Python toolchains. Comments indicate they were only disabled because Python 3 wasn't available on the Mac CI machines at the time. For pywrapper_test: this was failing because it copies system utilities (e.g `/usr/bin/which`) to another location and tries to run them. For newer MacOS versions, this results in a failure due AMFI (a security mechanism, see https://theevilbit.github.io/posts/amfi_launch_constraints/) To fix, instead of copying the binary, write a wrapper that re-execs the original binary. Work towards #16526, #8169 PiperOrigin-RevId: 507526814 Change-Id: Ifaacc30cb155af30af606254eb7ffcd9304478f6
hvadehra
pushed a commit
that referenced
this issue
Feb 14, 2023
This fixes the failures on MacOS after the recent upgrade to CI. When `//src/test/py/baze:runfiles_test` sets `--incompatible_use_python_toolchains=false`, it eventuallys tries to search `PATH` for `python`. This is because it falls back to the `--python_path` flag, which has a computed default of "python". Since new Mac versions no longer provide Python 2, this doesn't work. To fix, enable Python toolchains. Comments indicate they were only disabled because Python 3 wasn't available on the Mac CI machines at the time. For pywrapper_test: this was failing because it copies system utilities (e.g `/usr/bin/which`) to another location and tries to run them. For newer MacOS versions, this results in a failure due AMFI (a security mechanism, see https://theevilbit.github.io/posts/amfi_launch_constraints/) To fix, instead of copying the binary, write a wrapper that re-execs the original binary. Work towards #16526, #8169 PiperOrigin-RevId: 507526814 Change-Id: Ifaacc30cb155af30af606254eb7ffcd9304478f6
|
Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tracking bug for deleting
--incompatible_use_python_toolchains,--python_top,--python_path,--python2_path,--python3_path, and the legacy code supporting these flags.--python_pathis also tracked by #7901.We actually still depend on a variant of the legacy mechanism within Google, so this cleanup won't be completed anytime soon.
The text was updated successfully, but these errors were encountered: