Currently, proto targets for different languages are defined in a BUILD file by loading the xds_proto_package macro (eg. in //xds/data/orca/v3). The bzl file that defines xds_proto_package again loads macros from rules_go:
|
load("@io_bazel_rules_go//proto:def.bzl", "go_grpc_library", "go_proto_library") |
This is a bad practice because it forces any other project (see grpc) which depends on any target in //xds/data/orca/v3 to fetch rules_go, even though the project doesn't depend on the go_proto_library target. This is a common pitfall with Bazel, see bazelbuild/bazel#12835
A better package structure is to split targets into different packages by language, eg
- proto_library under //xds/data/orca/v3
- go_proto_library under //xds/data/orca/v3/go
- py_proto_library under //xds/data/orca/v3/py
- cc_proto_library under //xds/data/orca/v3/cc
so that dependencies for specific languages are not fetched when the corresponding package is not needed.
To maintain backwards compatibility, you can still have alias targets in //xds/data/orca/v3that points to other language specific packages.
Currently, proto targets for different languages are defined in a BUILD file by loading the xds_proto_package macro (eg. in
//xds/data/orca/v3). The bzl file that definesxds_proto_packageagain loads macros from rules_go:xds/bazel/api_build_system.bzl
Line 4 in 1e77728
This is a bad practice because it forces any other project (see grpc) which depends on any target in
//xds/data/orca/v3to fetch rules_go, even though the project doesn't depend on thego_proto_librarytarget. This is a common pitfall with Bazel, see bazelbuild/bazel#12835A better package structure is to split targets into different packages by language, eg
so that dependencies for specific languages are not fetched when the corresponding package is not needed.
To maintain backwards compatibility, you can still have
aliastargets in//xds/data/orca/v3that points to other language specific packages.