Skip to content
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

0.18.0 breaks compatibility for Bazel 5 #1056

Closed
faximan opened this issue Feb 10, 2023 · 6 comments · Fixed by #1061
Closed

0.18.0 breaks compatibility for Bazel 5 #1056

faximan opened this issue Feb 10, 2023 · 6 comments · Fixed by #1061

Comments

@faximan
Copy link

faximan commented Feb 10, 2023

🐞 bug report

Affected Rule

The issue is caused by the rule: python_register_toolchains

Is this a regression?

Yes, the previous version in which this bug was not present was: 0.17.3

Description

I think #977 broke the compatibility for Bazel versions <6 as the coverage_tool attribute on py_runtime was added in Bazel 6 .

I could not find it stated anywhere that this is WAI.

🔬 Minimal Reproduction

python_register_toolchains(
  name = "local_config_python",
  python_version = "3.9",
)
py_binary(
    name = "foo",
    srcs = ["foo.py"],
)

bazel-5.4.0 --bazelrc=/dev/null build //:foo

🔥 Exception or Error


ERROR: ~/.cache/bazel/_bazel_faximan/0920b5666e9ad52e0d97f6f97d994ed1/external/local_config_python_x86_64-unknown-linux-gnu/BUILD.bazel:62:11: @local_config_python_x86_64-unknown-linux-gnu//:py3_runtime: no such attribute 'coverage_tool' in 'py_runtime' rule

🌍 Your Environment

**Operating System: Debian

Output of bazel version:

  
Build label: 5.4.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Dec 15 16:14:25 2022 (1671120865)
Build timestamp: 1671120865
Build timestamp as int: 1671120865
  

Rules_python version:

  
0.18.0
  
@rickeylev
Copy link
Contributor

rickeylev commented Feb 11, 2023

Sorry about that. Thanks for the report. This looks like an easy fix. As an interim workaround, you can manually set register_coverage_tool=False

edit: the workaround doesn't actually work. Upgrade to 0.18.1

rickeylev added a commit that referenced this issue Feb 11, 2023
Only set `py_runtime.coverage_tool` for Bazel 6 and higher.

Avoid setting it in earlier version by checking `native.bazel_version`
in the repository rule and disabling it if less than Bazel 6 is
detected. A warning is also printed if coverage was requested, but
the Bazel version check is ignoring it.

Fixes #1056
@alexeagle
Copy link
Collaborator

@rickeylev I think that might not be the only problem? Even with register_coverage_tool=False in a Bazel 5 repo I get

ERROR: /shared/cache/bazel/user_base/31d1af6682b925f850635e639ebdf8e8/external/python3_8_x86_64-unknown-linux-gnu/BUILD.bazel:62:11: @python3_8_x86_64-unknown-linux-gnu//:py3_runtime: no such attribute 'coverage_tool' in 'py_runtime' rule
ERROR: /home/alexeagle/Projects/a/transcoding/v1/BUILD.bazel:44:10: Target '//a/transcoding/v1:transcoding_wheel.publish' depends on toolchain '@python3_8_x86_64-unknown-linux-gnu//:python_runtimes', which cannot be found: Target '@python3_8_x86_64-unknown-linux-gnu//:python_runtimes' contains an error and its package is in error'

We should add to the 0.18.0 release notes whatever answer we come up with for Bazel 5 users as well.

@rickeylev
Copy link
Contributor

That's weird. I manually tested a couple targets with 5.4 and things were OK. The only place I see coverage_tool even mentioned is in python/repositories.bzl. The only code path I see that would cause this would be if native.bazel_version was empty. Do you have a repro?

@alexeagle
Copy link
Collaborator

hmm, I got past it with some change, probably related to getting gazelle targets from load("@rules_python_gazelle_plugin//:* rather than load("@rules_python//gazelle:* which we've made awfully easy to get wrong...

rickeylev added a commit to rickeylev/rules_python that referenced this issue Feb 14, 2023
…ld#1061)

Only set `py_runtime.coverage_tool` for Bazel 6 and higher.

Avoid setting it in earlier version by checking `native.bazel_version`
in the repository rule and disabling it if less than Bazel 6 is
detected. A warning is also printed if coverage was requested, but
the Bazel version check is ignoring it.

Fixes bazelbuild#1056
rickeylev added a commit that referenced this issue Feb 14, 2023
Only set `py_runtime.coverage_tool` for Bazel 6 and higher.

Avoid setting it in earlier version by checking `native.bazel_version`
in the repository rule and disabling it if less than Bazel 6 is
detected. A warning is also printed if coverage was requested, but
the Bazel version check is ignoring it.

Fixes #1056
@carpenterjc
Copy link

I have run into this issue with bazel 5.3.2 and bazel 5.4.0. Works in 6.0.0
The problem is that the workaround only affects the select statement, so the attribute is still set.

Weirdly even if I add: load("@rules_python//python:defs.bzl", "py_runtime") to the top it still rejects the.

@rickeylev
Copy link
Contributor

Sorry, yes, the workaround I originally posted doesn't work. I updated that post to reflect this.

0.18.1 is now released with a fix for this: https://github.com/bazelbuild/rules_python/releases/tag/0.18.1

ianpegg-bc pushed a commit to ianpegg-bc/rules_python that referenced this issue May 12, 2023
…ld#1061)

Only set `py_runtime.coverage_tool` for Bazel 6 and higher.

Avoid setting it in earlier version by checking `native.bazel_version`
in the repository rule and disabling it if less than Bazel 6 is
detected. A warning is also printed if coverage was requested, but
the Bazel version check is ignoring it.

Fixes bazelbuild#1056
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants