-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some tests still require a python
binary (Python 2)
#16526
Comments
Most (all?) tests are actually PY3 compatible, i.e. a symlink to the python3 binary solved most of the problems. //src/test/shell/bazel:python_version_test is the only remaining failing test since it requires a |
python
binary (Python 2)
//src/test/py/bazel:runfiles_test is failing, too: logs |
FYI: I recently (~Jan 2023) did some work cleaning out Python 2 in Bazel. The aforementioned tests are probably OK now (several look familiar from what I cleaned up). You should also be able to set |
FWIW, several tests are failing this way today: https://buildkite.com/bazel/google-bazel-presubmit/builds/63119#01861694-4c8b-4d10-8232-67d46c3390cb |
|
For runfiles_test: The problem is the test is specifying I'm pretty sure all the "Could not find python binary: python" errors are this same cause. From what I remember, the above behavior is the only way to get just "python" as the interpreter name to use. I found the spot in runfiles_test doing this and will prepare a PR. I haven't grepped the other tests for The "Neither python or python3 was found on PATH" error is different; that will occur when toolchains are enabled. This is probably pywrapper_test doing weird setup; some of what it does is override PATH to run subprocesses to test logic. |
For pywrapper_test, this is some sort of issue with copying the
When copied to another location, the In any case, this shouldn't be too hard to work around in the test. I'll prep a PR. |
This change should unblock both pre- and post-submit. Related to bazelbuild#16526, bazelbuild#17407, bazelbuild#17408 and bazelbuild#17409. PiperOrigin-RevId: 506882975 Change-Id: If704c398546265eb22d58906eb28363b30ac00a2
This change should unblock both pre- and post-submit. Related to bazelbuild#16526, bazelbuild#17407, bazelbuild#17408 and bazelbuild#17409. PiperOrigin-RevId: 506882975 Change-Id: If704c398546265eb22d58906eb28363b30ac00a2
* Bazel CI: Disable tests that are failing due to infra upgrades. This change should unblock both pre- and post-submit. Related to #16526, #17407, #17408 and #17409. PiperOrigin-RevId: 506882975 Change-Id: If704c398546265eb22d58906eb28363b30ac00a2 * Bazel CI: Disable more tests that are likely failing due to infra updates. Related to #17410 and #17411. PiperOrigin-RevId: 506903607 Change-Id: Ic88de4caea5c14336774e53a9063a6beb260d515 * Disable python_version_test --------- Co-authored-by: Googler <[email protected]>
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
Looks like src/test/shell/bazel/remote_helpers.sh is another culprit using |
The new Mac images no longer have `python` (Python 2) Work towards #16526 PiperOrigin-RevId: 508136299 Change-Id: Ib4251081f79ac8deb48ce2f961527bb8de820b12
I wasn't able to get the android stuff working and I have to put this down for now, so won't be sending any more PRs on this for at least a few weeks. That said: I did some grepping and saw some places where The |
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
The new Mac images no longer have `python` (Python 2) Work towards #16526 PiperOrigin-RevId: 508136299 Change-Id: Ib4251081f79ac8deb48ce2f961527bb8de820b12
@rickeylev @fweikert Are there any more tests left broken due to this issue? |
Oh, I guess: |
Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale. |
This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please post |
Description of the bug:
On our new M1 Mac Studio CI workers the following tests fail due to Python 2 no longer being installed by default:
io_bazel/src/test/shell/bazel/bazel_example_test: line 135: python: command not found
logCould not find python binary: python
logObviously it would be easy to fix them by installing Python 2. However, I'd argue that the right thing is to switch to Python 3 given that it's 2022.
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
No response
Which operating system are you running Bazel on?
MacOS monterey 12.6 (Bazel CI)
What is the output of
bazel info release
?5.3.2
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: