feat(config): unify declarative and env-var configuration through a shared SDK orchestrator

Motivation

Today there are two independent configuration paths that construct the SDK:

1. Env-var path — _initialize_components() in opentelemetry/sdk/_configuration/__init__.py orchestrates SDK init, but env-var reading is scattered across individual SDK classes (TracerProvider, BatchSpanProcessor, Resource, MeterProvider, sampling, etc.). Each class reads its own OTEL_* vars at construction time.

2. Declarative file path — modular create_*/configure_* factory functions per signal (_tracer_provider.py, _logger_provider.py, _meter_provider.py, _propagator.py, _resource.py), but no top-level orchestrator that ties them together.

This split means:

• Env-var reading logic is duplicated or scattered, making it hard to maintain
• There's no single "apply this config" entry point for the declarative path
• The two paths can drift in behavior since they don't share construction logic

Proposal

1. Add a top-level configure_sdk(config) orchestrator

A single function that takes an OpenTelemetryConfiguration and calls all configure_* functions in the correct order:

def configure_sdk(config: OpenTelemetryConfiguration) -> None:
    resource = create_resource(config.resource)
    configure_tracer_provider(config.tracer_provider, resource)
    configure_meter_provider(config.meter_provider, resource)
    configure_logger_provider(config.logger_provider, resource)
    configure_propagator(config.propagator)

2. Add an env-var-to-config adapter

A function that reads all OTEL_* env vars and produces an OpenTelemetryConfiguration, which then flows through the same configure_sdk() path:

def load_config_from_env() -> OpenTelemetryConfiguration:
    """Read OTEL_* env vars and build an OpenTelemetryConfiguration."""
    ...

End state

YAML file → load_config_file() → OpenTelemetryConfiguration → configure_sdk()
env vars  → load_config_env()  → OpenTelemetryConfiguration → configure_sdk()

Both paths converge on the same construction logic, eliminating drift.

Considerations

• Scattered env-var reads in constructors: BatchSpanProcessor.__init__, TracerProvider.__init__, etc. read env vars when no explicit value is passed. Changing this touches public API surface and needs careful deprecation.
• Spec requirement: Individual components must respect env vars when no explicit config value is provided. A pure "read everything upfront" approach needs to distinguish "not configured" from "explicitly set to default".
• Backwards compatibility: The existing _OTelSDKConfigurator / _BaseConfigurator pattern is used by distros. Any refactor needs to preserve that extension point.
• Scope: This is a large refactor best done incrementally — start with configure_sdk() for the declarative path, then gradually migrate env-var reading.

Related

• #3631 — declarative config tracking issue

Start with _initialize_components() in opentelemetry/sdk/_configuration/init.py and the signal-specific _tracer_provider.py, _logger_provider.py, _meter_provider.py, _propagator.py, and _resource.py factories. Trace the existing _OTelSDKConfigurator and _BaseConfigurator extension points before defining the incremental scope. Done means the declarative path has a shared configure_sdk() entry point while preserving existing constructor behavior and distro compatibility.