Switch to gogo from goproto about go-control-plane HOT 9 CLOSED

i've no clue about bazel, but i'm think that shouldn't be a hard work to get going.

It's not hard work, but neither is it exactly easy.

I think there are really two use cases to consider:

1. library consumers
2. library contributors

For (1) I think it's pretty important to keep bazel out of the mix, for reasons we've previously discussed (TL;DR go libs should play nice with the standard go toolchain), so I'd definitely advocate for checking in the generated code, and considering it part of the library.

For (2), I think you can make the claim that the generated code should only change when something in data-plane-api changes; might it makes sense to make code generation part of that build/check-in process, producing a package that can then be vendored by go-control-plane? That keeps the bazelness associated with api changes constrained to a place that already requires it.

Just my 2¢.

from go-control-plane.

Relevant read:

• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md
• https://github.com/alecthomas/go_serialization_benchmarks

from go-control-plane.

from go-control-plane.

@kyessenov check out the protobuild package. docker swarm using the same approach as well.
example implementation https://github.com/containerd/containerd

from go-control-plane.

looks like a much cleaner interface.

from go-control-plane.

@roadrunner envoy API is using bazel for canonical build system. so all the gogoproto annotations and codegen will need to be wired through bazel (for better or worse).

from go-control-plane.

@kyessenov, in my company, we use makefile pretty much for all stuff like the build / test / gen.
i've no clue about bazel, but i'm think that shouldn't be a hard work to get going.

as long as proto files are not changed, you don't need to invoke the generation process.

generating go code from the proto files might be done manually, ie: make protos or go list ./... | grep -v vendor | xargs protobuild

some developers prefer the generation process manually, like;
(re)generate -> modify -> check-in -> release

others preferer CI pipelines, like;
modify protos -> check-in -> (ci hooks) (re)generate -> auto commit / tag generated

from go-control-plane.

from go-control-plane.

I encourage folks to add gogoproto annotations in data-plane-api where it makes sense (e.g. nullable, stdduration). I didn't do a full revision, but things will be discovered as we use xDS.

The generation script is mostly automated. I can run it once in awhile manually, since it's fairly simple. Doing automatic multi-repo sync is painful, as we observed first-hand in istio.

from go-control-plane.