Use of @// in bazelbuild/bazel/... makes it very hard to depend on Bazel from other repos

[jmillikin-stripe]

I want to build a Docker container that will run the prototype Bazel Remote Worker. This seems like it should be very easy, by creating a http_archive repo rule importing Bazel itself, and then making @io_bazel//src/tools/remote_worker) a dep of the image rule.

Unfortunately, the use of @// in this repo makes that very difficult. When a rule depends on @//foo:bar, Bazel will try to resolve //foo:bar as a target in the top-level workspace. Since the Bazel source is an external, that fails.

Luckily, Bazel's WORKSPACE declares workspace(name = "io_bazel"). This means a global search-and-replace of @// with @io_bazel// in this repo should allow it to be depended on normally, no further changes needed. I verified this by patching bazel-0.8.1 (https://gist.github.com/jmillikin-stripe/f53e098622bed7fb70a90103c80fc2ee) to use @io_bazel//, and was able to successfully build the remote worker as an external dep. This was the same output as building it from bazelbuild/bazel, including correctly vendored dependencies.

[laszlocsomor]

@dslomov , @aehlig : WDYT?

[dslomov]

Sounds like we should just use //foo:bar instead of @//foo:bar. This is canonical way of referring to 'the same repository'. @jmillikin-stripe if you submit a PR for that I'll gladly merge it.

[cgrushko]

Curious - I see that we ended up with @io_bazel//foo:bar instead of //foo:bar - is there a reason? I sent a PR that deletes @grpc_java from gRPC, and wondered if it's a valid thing to do.
Also, why was c7f2444 rolled back? I couldn't find the conversation around the commits.

[jmillikin-stripe]

//foo:bar and @//foo:bar are different. The first is a target in the local repository context, and the second is a target in the workspace default repository context.

It looks like the commit was rolled back for an unknown problem with one of the patch chunks. Lets discuss it on #4435.

[cgrushko]

@jmillikin-stripe my question was why @io_bazel//foo:bar and not //foo:bar. As dslomov says, "This is canonical way of referring to 'the same repository'. ".

[jmillikin-stripe]

I think you're getting confused between "git repository" and "bazel repository". Try this experiment:

• Edit your local Bazel checkout's third_party/googleapis/BUILD to replace load("@io_bazel//third_party/grpc:build_defs.bzl", "java_grpc_library") with load("//third_party/grpc:build_defs.bzl", "java_grpc_library")
• Try to build the Bazel binary in your modified client.
• Look at the resulting error messages, and dig into which paths Bazel is trying to load from in each case.

[cgrushko]

Ah. The reason is that third_party/googleapis/BUILD is not used in the main repository, where @io_bazel//foo:bar === //foo:bar.
It is used in an local external repository created by

new_local_repository(
    name = "googleapis",
    path = "./third_party/googleapis/",
    build_file = "./third_party/googleapis/BUILD",
)

in WORKSPACE.