Improve clarity of protobuf/grpc builder

vaticle / dependencies

Bazel dependency declarations for build tools reused across @vaticle repositories (only for @vaticle)

Mozilla Public License 2.0

12 stars 23 forks source link

What is the goal of this PR?

We've improved the clarity of our protobuf/grpc builder, renaming it to proto_grpc. This names it more accurately, rather than obscuring the protobuf aspect beneath GRPC. Previously this name made an amount of sense as we were only interested in GRPC.

This change was motivated by a desire to use protobuf-only java rules within TypeDB Platform.

What are the changes implemented in this PR?

We've renamed //builder/grpc to //builder/proto_grpc. We've also extended the builder to allow for just importing rules_proto_grpc rather than as well as GRPC.

This breaks existing usages of //builder/grpc. See below for a migration guide.

Migration

Where previously we used the following:

# Load //builder/grpc
load("@vaticle_dependencies//builder/grpc:deps.bzl", vaticle_grpc_deps = "deps")
vaticle_grpc_deps()

Now we do:

# Load //builder/proto_grpc
load("@vaticle_dependencies//builder/proto_grpc:deps.bzl", vaticle_proto_grpc_deps = "deps")
vaticle_proto_grpc_deps()

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

Trivial Change

[x] This change is trivial and does not require a code or architecture review.

Code

[ ] Packages, classes, and methods have a single domain of responsibility.
[ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
[ ] The code is canonical and the minimum required to achieve the goal.
[ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
[ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
[ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

[ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
[ ] Any required build and release automations are updated and/or implemented.
[ ] Any new components follows a consistent style with respect to the pre-existing codebase.
[ ] The architecture intuitively reflects the application domain, and is easy to understand.
[ ] The architecture has a well-defined hierarchy of encapsulated components.
[ ] The architecture is extensible and scalable.

vaticle / dependencies