In the review of #138 @cyrille-leclerc notes that when merged, otel-cli will be oblivious to OTEL_EXPORTER_OTLP_PROTOCOL, so it's possible for a user to set that envvar in conflict with otel-cli's assumptions, and create a broken situation.
To resolve this, otel-cli will need to support the OTEL_EXPORTER_OTLP_PROTOCOL variable and variants itself, and prioritize them over the rules documented in the README. This will allow for grpc to use http endpoints cleanly according to the spec, while allowing otel-cli to deviate a bit to provide a clearer UX to command-line users.
I'm going to merge #138 and will take care of this before releasing v0.1.0 (next release) so the behavior is set and consistent going forward.
In the review of #138 @cyrille-leclerc notes that when merged, otel-cli will be oblivious to
OTEL_EXPORTER_OTLP_PROTOCOL, so it's possible for a user to set that envvar in conflict with otel-cli's assumptions, and create a broken situation.To resolve this, otel-cli will need to support the OTEL_EXPORTER_OTLP_PROTOCOL variable and variants itself, and prioritize them over the rules documented in the README. This will allow for grpc to use http endpoints cleanly according to the spec, while allowing otel-cli to deviate a bit to provide a clearer UX to command-line users.
I'm going to merge #138 and will take care of this before releasing v0.1.0 (next release) so the behavior is set and consistent going forward.