Opentelemetry-go: How can we use OTLP protocol without exposing opentelemetry-proto-gen?

[jmacd]

For reasons that are (probably still) sensible, the go.opentelemetry.io/exporters/otlp/internal/opentelemetry-proto-gen is an internal package and I'm not able to depend on it for my own applications. Now suppose I've written an application that handles OTLP data itself but is also instrumented by an OTel-Go SDK. I need a copy of the OTLP protocol for my own application, but the Google and Gogo protocol buffer implementations emit warnings when you register the same protocol message name twice.

Simply put, if I generate my own copy of these protocol messages and link them with an OTel-Go SDK, I get a conflict. How should this be handled, in general? It seems to require the use of sed to change protocol package names, which leaves me in a complicated an unhappy position. As it stands, I do have such an application and I've manually done this once, but it was painful and it will happen the more people try to build custom OTLP pipelines.

Just looking for recommendations.

[seanschade]

I don't think it needs to be an internal package. It seems like the protocol is something you would want available as a Go package. As you pointed out someone can just generate their own stubs. If you move these stubs out now we can use a specific version, and know that they were generated consistently. This adds stability to the ecosystem.

[MrAlias]

@open-telemetry/technical-committee can we create a repository to host this generated code?

[tigrannajaryan]

@open-telemetry/technical-committee can we create a repository to host this generated code?

Why not host it in this repo? Alternatively, host in proto repo? (was discussed in the past and decided against, but can reopen the discussion).

[MrAlias]

@open-telemetry/technical-committee can we create a repository to host this generated code?

Why not host it in this repo? Alternatively, host in proto repo? (was discussed in the past and decided against, but can reopen the discussion).

I'd rather not host here given it is generated code from a different project. Hosting this in the proto repository sounds like a good solution to this as well.

[MrAlias]

Opened https://github.com/open-telemetry/opentelemetry-proto/issues/238 to track a potential solution in the proto repo.

[MrAlias]

A new repository has been created to host this generated code https://github.com/open-telemetry/opentelemetry-proto-go. My goal is to open issues there to build that up and take over the OTLP responsibilities from this repository. Stay tuned.