Unable to reference @bazel_tools//src/main/protobuf targets

[ghost]

Description of the problem / feature request:

I am unable to use Bazel's protobuf targets and sources---specifically extra_action_base_java_proto---directly from @bazel_tools//src/main/protobuf because of an unsatisfied dependency on @bazel_tools//tools/build_rules:genproto.bzl.

As a workaround, in order to use extra actions, my project's WORKSPACE needs to refer to and clone Bazel's source via git_repository. Cloning the full repository is slow, and needing to rev the SHA1 each time we upgrade Bazel is a pain.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

$ cat BUILD
java_binary(
    name = "dummy",
    srcs = ["src/main/java/Dummy.java"],
    main_class = "Dummy",
    deps = [
        "@bazel_tools//src/main/protobuf:extra_actions_base_proto",
    ],
)
$ bazel build :dummy
...
ERROR: .../dummy/BUILD:1:1: error loading package '@bazel_tools//src/main/protobuf': Unable to load file '@bazel_tools//tools/build_rules:genproto.bzl': file doesn't exist and referenced by '//dummy:dummy'
ERROR: Analysis of target '//dummy:dummy' failed; build aborted: error loading package '@bazel_tools//src/main/protobuf': Unable to load file '@bazel_tools//tools/build_rules:genproto.bzl': file doesn't exist

What operating system are you running Bazel on?

• Linux (CentOS 6.x, 7.x)
• macOS High Sierra and Mojave (10.13 and 10.14)

What's the output of bazel info release?

release 0.26.0+vmware

Have you found anything relevant by searching the web?

• extra_action doesn't document the proto it uses. #1188

[iirina]

Bazel needs to embed a custom @bazel_tools//src/main/protobuf/BUILD file instead of the one it uses itself, to avoid loading unnecessary depenencies that don't exist under @bazel_tools (e.g. //tools/build_rules:utilities.bzl, //tools/build_rules:genproto.bzl).

[thekyz]

any eta on when this could be solved?

[ghost]

I'm going to take a crack at this this week.

Would appreciate some suggestions for and from potential reviewers to nail down a few details:

• Should the embedded tools export the .proto files under @bazel_tools//src/main/protobuf or @bazel_tools//tools/protobuf?
  • I'm leaning toward //tools/protobuf, because TTBOMK all public @bazel_tools packages are rooted under //tools. This would also support aggregating .proto files not originally found in //src/main/protobuf, like src/main/java/com/google/devtools/build/lib/bazel/debug/workspace_log.proto and src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto. (These two are specifically referenced in public, user-facing documentation.)
• Is it fair to go ahead and export all .proto files found in //src/main/protobuf, or should the exported set be filtered/whitelisted? (I assume filtered based on

  bazel/src/main/protobuf/BUILD

  Lines 100 to 104 in d695d10

  	# This new option tagging method is in flux while being applied to the options
  	# in the Bazel code base. The visibility should not be changed to allow external
  	# dependencies until the interface has stabilized and can commit to maintaining
  	# backwards compatibility for 6 months' time.
  	# TODO(bazel-team) Make these visibility:public when the interface is stable.

  .)
  • Should this package bother exporting proto_library, java_proto_library, etc. rules as well, or just the .proto files, to begin?

[bartle-stripe]

@beasleyr-vmw any progress on this?

[ghost]

@bartle-stripe Thanks for the reminder. I put out a patch as a PR that we've used since February. It might give you something to work with if you build Bazel from source.

[fweikert]

I'm closing this issue since 0.26.0 is beyond its supported lifecycle. Please use a more recent version of Bazel, which should not suffer from this problem.