[Question] Importing generated proto go files from another source.

[gerardmrk]

Hi,

How do I go about fixing import path resolution when importing the generated proto go files from another go file?
Say I had this project structure:

├── BUILD
├── WORKSPACE
├── bazel-*.....
├── ...
├── client
│   ├── BUILD.bazel
│   └── main.go
├── customer
│   ├── BUILD.bazel
│   └── customer.proto
└── server
    ├── BUILD.bazel
    └── main.go

And I've verified that all targets builds successfully, and the generated go binaries also runs successfully. This is more IDE related: server/main.go imports the customer proto file but my IDE does not recognize it for obvious reasons, since the generated files are all in the bazel output folders, so I miss out on auto-completions and also a nagging squigly line.

I've diligently spent a whole Saturday morning googling this question and scouring the docs, but couldn't find anything regarding the topic, or wasn't sure if it was related to my issue at all. Since no one else is mentioning/complaining about this issue I'm assuming 90% of Bazel-Go-gRPC users already knows how to workaround this? Thanks in advance for any help/tip.

[gerardmrk]

for context, here is the customer/BUILD.bazel file:

load("@io_bazel_rules_go//go:def.bzl", "go_library")
load("@io_bazel_rules_go//proto:def.bzl", "go_proto_library")

proto_library(
    name = "customer_proto",
    srcs = ["customer.proto"],
    visibility = ["//visibility:public"],
)

go_proto_library(
    name = "customer_go_proto",
    compilers = ["@io_bazel_rules_go//proto:go_grpc"],
    importpath = "github.com/gerardmrk/sleepless/customer",
    proto = ":customer_proto",
    visibility = ["//visibility:public"],
)

go_library(
    name = "go_default_library",
    embed = [":customer_go_proto"],
    importpath = "github.com/gerardmrk/sleepless/customer",
    visibility = ["//visibility:public"],
)

and this is the server/BUILD.bazel file:

load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library")

go_library(
    name = "go_default_library",
    srcs = ["main.go"],
    importpath = "github.com/gerardmrk/sleepless/client",
    visibility = ["//visibility:private"],
)

go_binary(
    name = "client",
    embed = [":go_default_library"],
    visibility = ["//visibility:public"],
)

although its probably pointless to include them since there's nothing wrong with the builds itself

[ianthehat]

Issue #512 is tracking this.
Right now, pretty much everyone also wants their code to build with normal go build to they copy back the generated files, and still have the projects checked out into a valid GOPATH, which is about all you can do.
I am exclusively working on generalizing tools so they work with varying layouts and build systems now, along with some other people, but I don't have any kind of timeline I can give you for when it will be ready for use.

[gerardmrk]

Thanks for the heads up. I don't care about the timeline, I have no right to complain since I'm not contributing to the project.

It's enough information to know that I don't need to google/pursue a proper solution to this problem any further since there isn't one natively provided. Not familiar with github issues etiquette since I don't often post issues so not sure if it's my duty to close this issue or not. I'll let you do it? Will also appreciate tips for temporary workarounds. Right now I've resorted to manually running the protoc command each time.

In case anyone else bumps into this thread, it looks like you can automate this with Bazel's genrule syntax, but I haven't gotten it to work yet because of path resolution problems.

[jayconrod]

I'll close this as a duplicate of #512.

Sorry this is a pain right now. @ianthehat is working hard on making Go tools work with multiple build systems, but it will take some time.

A quick and dirty way to get the .pb.go files is to build the customer_go_proto target, then look in bazel-bin/ for something like linux_amd64_stripped/github.com/gerardmrk/sleepless/customer/customer.pb.go. I can't promise the paths to these files will be stable though over the long term.