kubernetes deps broken still

[jmhodges]

Okay, so if you build @io_k8s_client_go//kubernetes//typed/core/v1:go_default_library directly, it builds fine, but if you depend on it in another library, it breaks with:

$  bazel build //foo:go_default_library
ERROR: /private/var/tmp/_bazel_jmhodges/eb16c8c3f4af4addfaf08c38f6204969/external/io_k8s_api/core/v1/BUILD.bazel:18:1: no such package '@io_k8s_api//k8s.io/apimachinery/pkg/util/intstr': BUILD file not found on package path and referenced by '@io_k8s_api//core/v1:v1_go_proto'
ERROR: Analysis of target '//foo:go_default_library' failed; build aborted: no such package '@io_k8s_api//k8s.io/apimachinery/pkg/util/intstr': BUILD file not found on package path
INFO: Elapsed time: 0.197s
FAILED: Build did NOT complete successfully (0 packages loaded)

I've pushed up a branch with a reproduction. It's the k8s branch on jmhodges/bazel_bugs https://github.com/jmhodges/bazel_bugs/tree/k8s

You can run it with bazel build //foo:go_default_library.

[jmhodges]

Er, sorry, the "still" is referencing bazel-contrib/rules_go#1356 which was fixed (but apparently not completely) by the k8s repos removing their BUILD files.

[jmhodges]

(I assumed this was a gazelle generation bug, but maybe I should put this on rules_go?)

[jayconrod]

Unfortunately, this is an issue caused by Bazel's handling of proto import paths. I've pinged bazelbuild/bazel#4544. Once that feature is in, I think we'll be able to resolve a lot of problems.

There was a typo in the label you mentioned earlier. When I build @io_k8s_client_go//kubernetes/typed/core/v1:go_default_library (without the second double slash) I get the error. Not sure why Bazel doesn't complain about the second double slash; maybe a separate bug.

So we get an error building @io_k8s_client_go//kubernetes/typed/core/v1:go_default_library, which depends on @io_k8s_apimachinery//pkg/apis/meta/v1:v1_go_proto, which depends on @io_k8s_apimachinery//k8s.io/apimachinery/pkg/util/intstr:go_default_library, which is missing. The proto file imports k8s.io/apimachinery/pkg/util/intstr/generated.proto. This proto is not buildable with Bazel because proto_library requires import paths to be relative to repository roots.

Gazelle tries to interpret that import path the way Bazel would. It looks for a proto_library that includes the source file k8s.io/apimachinery/pkg/util/intstr/generated.proto, which does not exist. Failing that, it generates a dependency by following naming conventions. That's where //k8s.io/apimachinery/pkg/util/intstr:go_default_library comes from.

---

Gazelle's behavior here could be more intuitive. I don't think it makes sense to resolve local dependencies by following naming conventions anymore. Gazelle should report an error instead of providing a label which is almost certainly wrong.

[jmhodges]

Okay, per my comment in bazelbuild/bazel#3867 (which, for the audience at home, we got redirected to from bazelbuild/bazel#4544), I worked around this by deleting all of the proto files in k8s.io/api and /apimachinery and pushing them up to forks I control.

Blaaaaaaaah.

[drigz]

FYI, I've been able to build the out-of-cluster example against client-go at the recent kubernetes-1.11.0 tag (v8.0.0 hasn't been tagged/released yet) which removes the BUILD files, by using build_file_proto_mode = "disable" for io_k8s_api, io_k8s_apimachinery and com_github_googleapis_gnostic.