Skip to content

[bazel] Add fixes for --incompatible_load_proto_rules_from_bzl#20783

Merged
gnossen merged 1 commit intogrpc:masterfrom
Yannic:proto_incompat
Feb 7, 2020
Merged

[bazel] Add fixes for --incompatible_load_proto_rules_from_bzl#20783
gnossen merged 1 commit intogrpc:masterfrom
Yannic:proto_incompat

Conversation

@Yannic
Copy link
Copy Markdown
Contributor

@Yannic Yannic commented Oct 24, 2019

Starting soon, Protobuf rules will require explicit load statements
bazelbuild/bazel#8922

@yashykt

@linux-foundation-easycla
Copy link
Copy Markdown

linux-foundation-easycla bot commented Oct 24, 2019

CLA Check
The committers are authorized under a signed CLA.

@jtattermusch
Copy link
Copy Markdown
Contributor

@gnossen can you please review?

load("@com_github_grpc_grpc//third_party/py:python_configure.bzl", "python_configure")

def grpc_python_deps():
native.bind(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this constitute a breaking change for those who consume us?

Copy link
Copy Markdown
Contributor

@gnossen gnossen Oct 24, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that we're forced to do this because protobuf already made this breaking change. :/

@nicolasnoble Thoughts on yet another Bazel breaking change? As far as I can tell, the options are:

  • accept the breaking change and force all of our downstream users to do the same
  • get protobuf to roll back the change and potentially break users who have already accommodated it

Regardless, it's pretty clear that protobuf needs something like a Bazel distribtest.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this could break some consumers if they explicitly depend on how six is defined.
I still think it's worth moving away from bind().

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nicolasnoble and I talked offline. I agree that moving away from bind is the right option. But we can't just break backwards compatibility whenever we like. We'd like to batch up several backwards incompatible changes and synchronize them with our addition of official support for Bazel 1.0. We'll be discussing this in a meeting early next week. Until then, we'll need to put this change on hold.

@gnossen
Copy link
Copy Markdown
Contributor

gnossen commented Oct 24, 2019

Build failure from CI:

+ bazel test --spawn_strategy=standalone --genrule_strategy=standalone --test_output=errors //src/python/...
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
Loading:
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
DEBUG: /root/.cache/bazel/_bazel_root/d2dc70c3d9da3fab488ba0dcbbd35051/external/bazel_toolchains/rules/rbe_repo/checked_in.bzl:226:13: rbe_msan not using checked in configs; Bazel version 0.29.1 was picked/selected with '["9.0.0"]' compatible configs but none match the 'env = {"ABI_LIBC_VERSION": "glibc_2.19", "ABI_VERSION": "clang", "BAZEL_COMPILER": "clang", "BAZEL_HOST_SYSTEM": "i686-unknown-linux-gnu", "BAZEL_TARGET_CPU": "k8", "BAZEL_TARGET_LIBC": "glibc_2.19", "BAZEL_TARGET_SYSTEM": "x86_64-unknown-linux-gnu", "CC": "clang", "CC_TOOLCHAIN_NAME": "linux_gnu_x86", "BAZEL_LINKOPTS": "-lc++:-lc++abi:-lm"}', 'config_repos = None',and/or 'create_cc_configs = True' passed as attrs
Analyzing: 169 targets (28 packages loaded, 0 targets configured)
Analyzing: 169 targets (69 packages loaded, 783 targets configured)
Analyzing: 169 targets (69 packages loaded, 783 targets configured)
Analyzing: 169 targets (69 packages loaded, 783 targets configured)
ERROR: /root/.cache/bazel/_bazel_root/d2dc70c3d9da3fab488ba0dcbbd35051/external/com_github_grpc_grpc/bazel/grpc_python_deps.bzl:8:9: in http_archive rule //external:six: Found reference to a workspace rule in a context where a build rule was expected; probably a reference to a target in that external repository, properly specified as @reponame//path/to/package:target, should have been specified by the requesting rule.
ERROR: Analysis of target '//src/python/grpcio_tests/tests/unit:_abort_test.python3' failed; build aborted: Analysis of target '//external:six' failed; build aborted
INFO: Elapsed time: 24.682s
INFO: 0 processes.

Copy link
Copy Markdown
Contributor Author

@Yannic Yannic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your review! ptal

load("@com_github_grpc_grpc//third_party/py:python_configure.bzl", "python_configure")

def grpc_python_deps():
native.bind(
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this could break some consumers if they explicitly depend on how six is defined.
I still think it's worth moving away from bind().

@Yannic
Copy link
Copy Markdown
Contributor Author

Yannic commented Dec 16, 2019

@gnossen Any news on this?

@gnossen
Copy link
Copy Markdown
Contributor

gnossen commented Jan 6, 2020

@Yannic Sorry for the long delay. It's clear that this is the only way we're going to be able to update our protobuf dependency, so I'd like to go ahead and fast track this for merge.

@gnossen
Copy link
Copy Markdown
Contributor

gnossen commented Jan 8, 2020

@Yannic

ERROR: /root/.cache/bazel/_bazel_root/d2dc70c3d9da3fab488ba0dcbbd35051/external/com_github_grpc_grpc/bazel/grpc_python_deps.bzl:8:9: in http_archive rule //external:six: Found reference to a workspace rule in a context where a build rule was expected; probably a reference to a target in that external repository, properly specified as @reponame//path/to/package:target, should have been specified by the requesting rule.
ERROR: Analysis of target '//src/python/grpcio_tests/tests_aio/benchmark:server' failed; build aborted: Analysis of target '//external:six' failed; build aborted
INFO: Elapsed time: 22.044s
INFO: 0 processes.

There are still some issues with the six changes. I'd suggest find src examples -name 'BUILD*' | xargs grep six to make sure you've got everything. For reference, I also recently tackled this problem in another PR (319686f) and that fully resolved the six build issues. Feel free to cherrypick if it helps.

@Yannic
Copy link
Copy Markdown
Contributor Author

Yannic commented Jan 8, 2020

Thanks for pinging. I'll take a look tomorrow.

@Yannic
Copy link
Copy Markdown
Contributor Author

Yannic commented Jan 10, 2020

This is partly superseded by #21590, so let's wait until that lands as this will likely show the same issues with blacklisted protos.

@Yannic
Copy link
Copy Markdown
Contributor Author

Yannic commented Feb 5, 2020

@gnossen I finally found the time to update this. platl

@gnossen
Copy link
Copy Markdown
Contributor

gnossen commented Feb 5, 2020

Awesome! Running CI on it.

@Yannic
Copy link
Copy Markdown
Contributor Author

Yannic commented Feb 7, 2020

Thanks @gnossen! CI failures look unrelated.

@gnossen
Copy link
Copy Markdown
Contributor

gnossen commented Feb 7, 2020

Failures:

@gnossen gnossen merged commit a2e4a23 into grpc:master Feb 7, 2020
@gnossen
Copy link
Copy Markdown
Contributor

gnossen commented Feb 7, 2020

@Yannic Thanks for the contribution!

@Yannic Yannic deleted the proto_incompat branch February 8, 2020 12:05
@lock lock bot locked as resolved and limited conversation to collaborators May 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants