How come opentelemetry-proto is optional to opentelemetry-sdk?

[amirebrahimi]

I'm encountering an issue with ray-project/ray#61530 and trying to understand if the issue is on their side or if it is because there isn't a proper dependency within opentelemetry-sdk/api to include a newer version of opentelemetry-proto

[adilburaksen]

opentelemetry-proto is optional to opentelemetry-sdk because the SDK is transport-agnostic — it doesn't require OTLP specifically. You can use the SDK with other exporters (console exporter, Zipkin, custom exporters, etc.) that have nothing to do with Protocol Buffers.

The dependency chain works like this:

opentelemetry-sdk          # core SDK — defines Tracer, Span, Exporter interface
    └── (optional) opentelemetry-exporter-otlp-proto-grpc   # OTLP over gRPC
    │       └── opentelemetry-proto                          # protobuf bindings
    └── (optional) opentelemetry-exporter-otlp-proto-http   # OTLP over HTTP/protobuf
            └── opentelemetry-proto                          # protobuf bindings

opentelemetry-proto only becomes a real dependency when you install one of the OTLP exporters. This keeps the core SDK footprint small for users who export via other means or write custom exporters.

---

Regarding the Ray issue (#61530):

This pattern causes version conflicts because Ray pins opentelemetry-proto to a specific version internally, while a newer opentelemetry-sdk or OTLP exporter may expect a different version. Since opentelemetry-proto is listed as optional/indirect in the SDK's metadata, pip/uv dependency resolvers can end up pulling in the version Ray wants rather than the version your OTLP exporter needs.

Workaround: explicitly pin opentelemetry-proto to the version required by your opentelemetry-sdk:

# Find the expected version
pip show opentelemetry-exporter-otlp-proto-grpc | grep opentelemetry-proto

# Then pin it explicitly in your requirements
opentelemetry-proto==1.x.y

Or, check if your OTel package versions are all from the same release (they all version-lock together, e.g., all 1.27.0).

This is a known pain point in ecosystems that bundle OTel (Ray, LangChain, etc.) — the fix is usually to align all opentelemetry-* packages to the same version.