search

bufbuild / buf

The best way of working with Protocol Buffers.
https://buf.build
Apache License 2.0
8.93k stars 267 forks source link

Buf remote generation and external packages #1125

Closed jon-whit closed 2 years ago

jon-whit commented 2 years ago

I have a module that I've pushed to the Buf Registry, and I've setup remote generation to generate the sources for Go. The template I'm using includes the protoc-gen-validate and grpc-gateway plugins. The Go module that the Buf GOPROXY provides is imported in a project that manages it's own protobufs for its own API, and this project uses these same remote plugins protoc-gen-validate and grpc-gateway.

This leads me to the notorious golang/protobuf global registry problem. The error I get is this:

panic: proto: file "validate/validate.proto" is already registered
    previously from: "github.com/envoyproxy/protoc-gen-validate/validate"
    currently from:  "go.buf.build/openfga/go/envoyproxy/protoc-gen-validate/validate"
See https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict

Is there a way to have the Buf remote generation engine use a specific Go module for a dependent package. For example, in this case, is it possible to have Buf use github.com/envoyproxy/proco-gen-validate/validate as the Go module instead of go.buf.build/openfga/go/envoyproxy/protoc-gen-validate/validate? If it could do this, then that would resolve my issue because I wouldn't have a namespace collision on these protobuf sources.

amckinney commented 2 years ago

We synced up offline here a while back, but we solved this issue by using Managed Mode's override feature. In this case, we were able to override the value of the go_package option for the files in question.

For example, this would look something along the lines of the following (on a per-file basis):

version: v1
managed:
  enabled: true
  override:
    GO_PACKAGE:
      validate/validate.proto: github.com/envoyproxy/proco-gen-validate/validate
plugins:
  - ...

For more information, check out the override documentation.

@jon-whit if you have any other context you'd like to share from our previous conversation, please do so. Otherwise, closing this as-is.