go_repository importpath not observed for understanding imports inside .protos

[nictuku]

It's currently not possible to build a kubernetes client in Go due to various issues, one of them being the fact that various core k8s .proto files do things like this https://github.com/kubernetes/api/blob/master/core/v1/generated.proto#L24

That's a:
import "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1beta1/generated.proto";

Here's an attempt to build a simple Go server that use k8s.io/client-go/kubernetes:

$ blaze build :kubernetes
ERROR: /private/var/tmp/_bazel_yves/0c54c9294d330f944cc0ce0c84bc0f28/external/io_k8s_api/core/v1/BUILD:76: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 '//:kubernetes' 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: 10.791s

Note that Bazel (gazelle?) mapped the proto import to a package called @io_k8s_api//k8s.io/apimachinery/pkg/util/intstr. The thing is, my workspace already has a go_repository with the importpath k8s.io/apimachinery so Bazel should be using that.

Here's a repo with an independent workspace where I'm attempting to build a working kubernetes client-go and documenting the various issues I'm encountering: https://github.com/nictuku/k8s-bazel-go-example

This is the most problematic of them.

[jayconrod]

Thanks for reporting. At the moment, Gazelle relies on naming conventions. It uses some fairly simple transformations to convert imports extracted from source files into Bazel labels. I'm working on making it smarter. When #859 is closed (hopefully by the end of the week), Gazelle will be aware of rules defined within a repository. The long-term plan is for Gazelle to be aware of rules in other repositories so that it can manage WORKSPACE dependencies.

[jayconrod]

Closing old Gazelle issues.

bazel-contrib/bazel-gazelle#13 covers associating import paths with go_repository rules. However, that will likely only apply for Go.

bazel-contrib/bazel-gazelle#12 covers indexing library rules in external repositories and using those to resolve dependencies. So that's a partial fix.

proto_library import paths must be relative to a repository root though.

As I understand, proto_library import paths must be relative to the root of a repository. They can't include the repository URL. So with the import string mentioned above, there needs to be some repository with a file at //k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1beta1/generated.proto. This is an unfortunate limitation, especially in the case of vendoring. bazelbuild/bazel#3867 is a feature request to let proto_library specify a virtual path for itself.