Gazelle doesn't know how to handle imports from google/api/*.proto

[achew22]

In a cursory glance it looks like these should come from https://github.com/googleapis/googleapis/blob/master/google/api/. Is it possible to specify that these are external deps and should be loaded from a @external_repo?

[jayconrod]

Not really sure what Gazelle can do with that directory without adding a lot of special cases. There are a large number of .proto files with no BUILD file.

I think there would need to be a handwritten BUILD file in that directory (either upstreamed, or emplaced with a repository rule) that defines proto_library and go_proto_library. When #12 is implemented, Gazelle would index these rules. When you import one of these proto files, it would resolve the dependency to the proto_library or go_proto_library as appropriate. WDYT?

[ashi009]

I'd go with external repo. As long as the generated build file is not using "//google/api" as target, I don't have to touch the build file and add #gazelle:ignore on the top.

I've already tried to use new_repository with a local build file as temp fix, which seems not a huge maintenance burden.

[jayconrod]

There's no way to tell whether a proto import is from an external repo or not just by looking at the import string (without special cases). They're paths that are relative to the repo root, but they could be in any repo including the workspace.

When #12 is working, we'll have an index of all the proto files in external repos, so Gazelle will be able to generate correct targets. I think that will fix it.

[ashi009]

SG. I'll manually put these files in my workspace and put a huge DO NOT EDIT in the readme for now.

It's indeed annoying to work with these special cases, as the import syntax in proto files is not built for open source world at first place :(

[ashi009]

@jayconrod Indexing files in current workspace works already, and I think the external one seems can be solved by using repo overlays as the build files in third_party directory. Is this the direction gazelle moves toward to? I'd love to give it a shot if that's the long term plan.

[jayconrod]

@ashi009 Sorry for the slow response; just got back from a trip.

The long-term plan for repositories that need some customization (that go_repository doesn't work for) is to use overlay build files (via Gazelle's http_archive and git_repository). The build files will be stored in a third_party directory and will be kept up to date with Gazelle, but they can have manual customizations, too.

The command to add a new repository to one of these rules or migrate an existing go_repository will look something like this:

gazelle update-repos -rule=git_repository example.com/repo

After that, you'll be able to update to a new commit and update build files at the same time with gazelle update-repos example.com/repo or gazelle update-repos -all.

I was hoping to have this working already, but a bunch of stuff has been happening in rules_go, so most of my attention has been there. I still hope to get this done soon.

[jayconrod]

Closing this since Gazelle 0.13.0 includes special cases for protos in github.com/googleapis/googleapis and for the Well Known Types.