bazelbuild / bazel-gazelle

Gazelle is a Bazel build file generator for Bazel projects. It natively supports Go and protobuf, and it may be extended to support new languages and custom rule sets.
Apache License 2.0
1.19k stars 378 forks source link

Cannot have 2 rules, one for testing code and the other for non-testing code #1365

Open seungduk-yanolja opened 1 year ago

seungduk-yanolja commented 1 year ago

What version of gazelle are you using?

v0.27.0

What version of rules_go are you using?

v0.35.0

What version of Bazel are you using?

Bazelisk version: development Build label: 5.3.1 Build target: bazel-out/darwin_arm64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar Build time: Mon Sep 19 17:37:11 2022 (1663609031) Build timestamp: 1663609031 Build timestamp as int: 1663609031

Does this issue reproduce with the latest releases of all the above?

Yes

What operating system and processor architecture are you using?

Darwin 21.6.0 Darwin Kernel Version 21.6.0: xnu-8020.140.49~2/RELEASE_ARM64_T6000 arm64

What did you do?

There are 2 rules, one for testing and the other one for prod code.

go_library(
    name = "aws",
    srcs = [
        "config.go",
        "dynamodb.go",
        "dynamodb_createitem.go",
        "dynamodb_getitem.go",
    ],
    ...
)

go_library(
    name = "fake",
    testonly = True,
    srcs = ["fake_dynamodb.go"],
    ...
)

They share the same package, aws. I want to separate the rules and isolate the code for testing. I do not want the code for testing is exposed to non-testing code. Gazelle adds the file for testing to the aws rule and also complains that it is ambiguous what to import.

What did you expect to see?

No error

What did you see instead?

gazelle: rule @***//***/*** imports "***/***/golang/aws" which matches multiple rules: @***//***/*** and @***//***/***:fake. # gazelle:resolve may be used to disambiguate
gazelle: rule @***//***/***:***_test imports "***/***/golang/aws" which matches multiple rules: @***//***/*** and @***//***/***:fake. # gazelle:resolve may be used to disambiguate
achew22 commented 1 year ago

How would you achieve this using the normal go tooling?

seungduk-yanolja commented 1 year ago

How would you achieve this using the normal go tooling?

There are many things not possible without Bazel and this is the reason why I am using it :)

achew22 commented 1 year ago

While it's possible to set importpath differently been two go_library targets in rules_go, and this is how you would go about doing it if you dead set on it, gazelle isn't glaze only generates targets from standard go tooling compatible code as it stands.

That said, a go tooling compatible strategy you might consider would be having an internal package in the directory you would like to have multiple entries for. That package can contain inaccessible implementation details and you can export what is reasonable outside of internal, or maybe make a footest package a la net/http/httptest>

Let's spit ball some more ideas here if you've got any alternatives you are considering