Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect proto_library deps when strip_import_prefix, --index=false and mode=file #1934

Open
nchepanov opened this issue Sep 24, 2024 · 2 comments

Comments

@nchepanov
Copy link

What version of gazelle are you using?

Latest, v.0.39.0

What version of rules_go are you using? / What version of Bazel are you using? / Does this issue reproduce with the latest releases of all the above?

N.A.

What operating system and processor architecture are you using?

Darwin nchepanov-mac 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000 arm64 MacOS 14.6.1

What did you do?

Reproducer https://github.com/nchepanov/gazelle-strip-import-prefix-index-off/

In our repository all protos live in a special directory within the monorepo. For historical reasons they reference each other relative to the directory, not the repository root. We are trying to speed up gazelle by using --index=false but it seems to break the proto_strip_import_prefix directive rewriting of the imports during language/proto/resolve.go:resolveProto()

In essence, --index=false + strip_import_prefix results in dropping the //prefix in deps that was there with indexing on

diff --git a/prefix/foo/BUILD.bazel b/prefix/foo/BUILD.bazel
index fab6b89..037722e 100644
--- a/prefix/foo/BUILD.bazel
+++ b/prefix/foo/BUILD.bazel
@@ -5,5 +5,5 @@ proto_library(
    srcs = ["foo.proto"],
    strip_import_prefix = "/prefix",
    visibility = ["//visibility:public"],
-    deps = ["//prefix/moo:moo_proto"],
+    deps = ["//moo:moo_proto"],
)

What did you expect to see?

The strip_import_prefix attribute is generated in both situations, so the root BUILD.bazel file was read with or without indexing. The deps attribute should be the same in both cases.

@nchepanov

This comment was marked as outdated.

@nchepanov
Copy link
Author

UPD: In a general case, such mapping is impossible without indexing, however in our case with mode=file, index=false, strip_import_prefix=set the tail end of the resolveProto() function can actually use this knowledge to map import to deps without index: https://github.com/bazelbuild/bazel-gazelle/blob/d16fc424cfcfdbd8893a267e500ec5d04ec0bbf0/language/proto/resolve.go#L145-L152

The following work in progress PR (please ignore changes to resolve.go) nchepanov#1 contains a fully functional test that fails as expected, showcasing the unsupported edge-case.

For now, I don't have more time to dig more into this, I ended up solving this in our custom language by using CrossResolve that was introduced in #771 to support a very similar use-case: full indexing is too slow.

For reference, a super simple CrossResolve impelmentation ended up looking like this

func (l *customLang) CrossResolve(c *config.Config, ix *resolve.RuleIndex, imp resolve.ImportSpec, lang string) []resolve.FindResult {
	if lang == "proto" && imp.Lang == "proto" {
		rel := path.Dir(imp.Imp)
		if rel == "." {
			rel = ""
		}
		filename := strings.TrimSuffix(path.Base(imp.Imp), ".proto")
		return []resolve.FindResult{
			{Label: label.New("", path.Join("prefix", rel), proto.RuleName(filename))},
		}
	}
	return nil
}

@nchepanov nchepanov changed the title Incorrect proto_library deps generated with strip_import_prefix when --index=false Incorrect proto_library deps generated with strip_import_prefix when --index=false and mode=file Sep 25, 2024
@nchepanov nchepanov changed the title Incorrect proto_library deps generated with strip_import_prefix when --index=false and mode=file Incorrect proto_library deps when strip_import_prefix, --index=false and mode=file Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant