cc @open-telemetry/python-approvers @open-telemetry/java-approvers

However, Java's implementation seems closer to the Ruby PR. Configuration is skipped, but I don't know enough about Java to know if that means you cannot create working tracers, etc.

If you are using the Java autoconfigure module and set OTEL_SDK_DISABLED=true then none of the autoconfigure callbacks to customize the OpenTelemetry SDK are called, and so there's no way to add your own tracers etc.

If you are using the Java autoconfigure module and set OTEL_SDK_DISABLED=true then none of the autoconfigure callbacks to customize the OpenTelemetry SDK are called, and so there's no way to add your own tracers etc.

Thanks for clarifying, @trask. Is there a way for to use the Java SDK without the autoconfigure module? If so, does OTEL_SDK_DISABLED have any impact on that path?

ya, you can use the Java SDK without the autoconfigure module, in which case OTEL_SDK_DISABLED has no effect

Thanks, @trask!

@open-telemetry/python-approvers - Am I reading your code correctly, will OTEL_SDK_DISABLED create no-ops for all attempts at creating tracer providers, etc.?

@trask thinking about your response, and reading the spec, should OTEL_SDK_DISABLED also have effect with custom SDK config (i.e. without autoconfigure)?

The way I read it

a no-op SDK implementation will be used for all telemetry signals

I understand that if I pass OTEL_SDK_DISABLED then a no-op SDK would override any other config?

@trask thinking about your response, and reading the spec, should OTEL_SDK_DISABLED also have effect with custom SDK config (i.e. without autoconfigure)?

I think this falls under (emphasis added) https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#implementation-guidelines:

Environment variables MAY be handled (implemented) directly by a component, in the SDK, or in a separate component (e.g. environment-based autoconfiguration component).

Thanks, @trask!

@open-telemetry/python-approvers - Am I reading your code correctly, will OTEL_SDK_DISABLED create no-ops for all attempts at creating tracer providers, etc.?

It return no-ops when calling get_logger, get_tracer and get_meter of the sdk signals providers, so it's not a no-op tracer provider but a no-op tracer.

I think this falls under (emphasis added) https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#implementation-guidelines:

Environment variables MAY be handled (implemented) directly by a component, in the SDK, or in a separate component (e.g. environment-based autoconfiguration component).

@trask - I'm not sure I understand how this answers @danielgblanco's question. Does this mean an implementation can choose to apply an environment variable configuration only in an autoconfiguration component and have no impact on lower-level ways to access the SDK?

Does this mean an implementation can choose to apply an environment variable configuration only in an autoconfiguration component and have no impact on lower-level ways to access the SDK?

yeah, this is how Java SDK works. the SDK itself has no knowledge of env vars. you have to use a separate autoconfigure module in order to create an instance of the SDK based on env vars

there are definitely pros and cons of this approach, I'd probably look at a couple of other language implementations and consider what would be best specifically for Ruby

also keep in mind that future otel configuration will be built on top of declarative config in case that has any affect on your thinking