Related Problems?

Related to OTLP refactoring work: #3045

Describe the solution you'd like:

Enabling the OTLP "http-json" feature results in prost being pulled in and compiled, even though it isn't needed for OTLP/JSON.

> cd opentelemetry-otlp
> cargo tree --no-default-features --features http-json --invert prost
prost v0.14.1
├── opentelemetry-otlp v0.31.0
├── opentelemetry-proto v0.31.0
│   └── opentelemetry-otlp v0.31.0
└── tonic-prost v0.14.5
    └── opentelemetry-proto v0.31.0

Since the OTLP types are generated through prost-build, there's no straightforward way to make prost itself optional.

e.g. ideally:

#[cfg_attr(feature = "with-schemars", derive(schemars::JsonSchema))]
#[cfg_attr(feature = "with-serde", derive(serde::Serialize, serde::Deserialize))]
#[cfg_attr(feature = "with-serde", serde(rename_all = "camelCase"))]
#[derive(Clone, PartialEq, ::prost::Message)]
pub struct ExportMetricsServiceRequest {
    ...
}

would have ::prost::Message be wrapped in a cfg_attr.

Considered Alternatives

No response

Additional Context

Given that prost is only passively maintained now, it might be a concern being tied to it for type generation.

Decoupling the types would also likely make it easier to support the official protobuf crate, or alternatives like Anthropic's buffa in the future too.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}