Gazelle generates incorrect deps path to internal .proto dependencies in proto_library

[BeHustle]

This happens if one buf.yaml file is used for several .proto libraries. In your example it happens in the following case:

• Remove buf.yaml from fooapis rm examples/gazelle/fooapis/buf.yaml
• Move examples/gazelle/barapis/buf.yaml to parent directory (it has common deps for both fooapi and barapi) mv examples/gazelle/barapis/buf.yaml examples/gazelle/buf.yaml
• Export buf.yaml in examples/gazelle/BUILD.bazel
• Remove BUILD.bazel fooapis and barapis for regenerates Gazelle rm examples/gazelle/fooapis/foo/v1/BUILD.bazel rm examples/gazelle/barapis/bar/v1/BUILD.bazel

• Run gazelle

  Аfter that, the following code is generated in the examples/gazelle/fooapis/v1/BUILD.bazel

  proto_library( name = "foo_v1_proto", srcs = ["foo.proto"], visibility = ["//visibility:public"], +deps = ["@buf_deps//bar/v1:v1_proto"], -deps = ["//barapis/bar/v1:bar_v1_proto"], )

[srikrsna-buf]

Hey @BeHustle! Thank you for the detailed steps to reproduce. I can confirm the behaviour that you highlighted.

After the changing the location of the buf.yaml, the import path for bar.proto changes to barapis/bar/v1/bar.proto. Updating fooapis/foo/v1/foo.proto to use the correct import path fixes the issue and gazelle accurately generates the rule.

As of now, if the gazelle extension cannot find the proto file at the import location it falls back to the dependency rule if present. It does not check whether the import is part of the dependency tree or not. I'll create an issue to track this and gazelle should return an error if this is the case.

Thank you for reporting. I'll close this issue and link this to the new issue. Feel free to reopen if I missed something.