feat(config): extract declarative configuration into opentelemetry-configuration package#5356
feat(config): extract declarative configuration into opentelemetry-configuration package#5356MikeGoldsmith wants to merge 14 commits into
Conversation
…n package Per the Python SIG on 2026-06-25 (tracked in open-telemetry#5355), declarative configuration moves out of opentelemetry-sdk into a new standalone package. The SDK stays slim and stable; declarative-config-specific code lives in opentelemetry-sdk-configuration which can iterate and version independently with an experimental marker. Layout: opentelemetry-sdk-configuration/ pyproject.toml new package manifest README.rst experimental marker, install hint src/opentelemetry/sdk/configuration/ the public namespace __init__.py public API: configure_sdk, load_config_file, OpenTelemetryConfiguration, ConfigurationError _exceptions.py, _common.py, _conversion.py, _sdk.py, _resource.py, _propagator.py, _tracer_provider.py, _meter_provider.py, _logger_provider.py, models.py, schema.json file/__init__.py, file/_loader.py, file/_env_substitution.py version/__init__.py 0.1.0.dev codegen/dataclass.jinja2 moved from opentelemetry-sdk/codegen tests/ all moved from opentelemetry-sdk/tests/_configuration test-requirements.txt opentelemetry-sdk keeps only what activates the declarative path: - OTEL_CONFIG_FILE env var constant in opentelemetry.sdk.environment_variables - _OTelSDKConfigurator._configure detects the env var and lazy-imports opentelemetry.sdk.configuration. The SDK has no runtime dep on the new package; lambda / no-config users pay zero import cost. - When OTEL_CONFIG_FILE is set but the new package isn't installed, raise a clear RuntimeError with a pip-install hint instead of a bare ImportError. Top-level updates: - pyproject.toml: codegen input/output paths and additional-imports point at the new package. ruff per-file-ignore for test_models.py updated. file-configuration extras moved off opentelemetry-sdk. - tox.ini: adds test-/lint- envs for opentelemetry-sdk-configuration; coverage env switches from opentelemetry-sdk[file-configuration] to the standalone configuration package. Tests: - 309 tests in opentelemetry-sdk-configuration/tests pass. - 789 tests in opentelemetry-sdk/tests pass (incl. rewritten test_configurator_file_routing.py which now patches the new module paths and covers the missing-package RuntimeError). Closes open-telemetry#5355
…lint/typecheck on lazy import, fix link-check placeholder
| @@ -0,0 +1 @@ | |||
| Declarative configuration moves from `opentelemetry.sdk._configuration` into the new public `opentelemetry-sdk-configuration` package (`opentelemetry.sdk.configuration` namespace), published experimentally and versioned independently of the SDK. | |||
There was a problem hiding this comment.
Can you prefix this with opentelemetry-sdk-configuration?
|
I'm somewhat suprised this package structure is installable alongside the This should probably be fine at runtime, can we verify that type checking works properly for someone using both |
…r namespace package; revert lint/typecheck workarounds
…(module path opentelemetry.configuration); restore sdk __init__.pyi
| members = [ | ||
| "opentelemetry-api", | ||
| "opentelemetry-sdk", | ||
| "opentelemetry-configuration", |
There was a problem hiding this comment.
can you also add to the typecheck include list?
Thanks @herin049. I've decided to rename to Two things pushed me that way.
Since we no longer extend Let me know what you think. |
…ration import (not installed in sdk lint env)
I think this is the right call, we can always keep a lightweight user-facing API in |
| "Typing :: Typed", | ||
| ] | ||
| dependencies = [ | ||
| "opentelemetry-api == 1.44.0.dev", |
There was a problem hiding this comment.
I have a few questions/comments on the dependencies here.
- Can we loosen the SDK/API compatibility by declaring
opentelemetry-api ~= 1.44.0.dev(and likewiseopentelemetry-sdk) so that this package can rely on newer versions of the API/SDK. This should be safe to do as long as we don't rely on anything internal to the API/SDK that could break across minor versions. Edit: Actually, we probably need to pin as you have here because we support developmental/unstable functionality from the SDK. - Is
typing-extensionsexplicitly used in this package, and/or is it only used within aTYPE_CHECKINGblock? If not, we can probably remove this dependency. - Can we make
pyyaml >= 6.0an optional dependency, perhaps under the extrayaml? I'm not sure how common it is, but it's possible that some users may choose not to read directly from a YAML file (e.g. JSON instead). If you don't think this is that common, I'm fine with keeping it in the default dependencies. - On a similar note to 3. can we make the version ranges for the
pyyamlandjsonschemadependencies a little looser, to give our user's a more flexible compatibility window?
Description
Per the Python SIG on 2026-06-25, declarative configuration moves out of
opentelemetry-sdkinto a newopentelemetry-configurationpackage. The SDK stays slim and stable; declarative config lives in its own package with public types, an experimental marker, and an independent release cadence.Core changes
opentelemetry-configurationpackage owns the schema, models, loader, env substitution,configure_sdk, per-signal factories, and exceptions. Public namespace isopentelemetry.configuration(the oldopentelemetry.sdk._configurationprivate namespace is dropped, no shim).pyyamlandjsonschemaare required runtime dependencies.opentelemetry-sdkkeepsOTEL_CONFIG_FILEand the_OTelSDKConfiguratoractivation hook. When the env var is set, it lazy-imports the new package and callsconfigure_sdk(load_config_file(path)); otherwise no import happens, so users who don't opt in pay zero cost.OTEL_CONFIG_FILEis set butopentelemetry-configurationis not installed, the SDK raises aRuntimeErrorwith a pip-install hint instead of a bareImportError.pyproject.tomlcodegen,tox.inienvs, and CI workflows are updated accordingly.Closes #5355
Refs #3631
Type of change
opentelemetry.sdk._configurationpaths)How Has This Been Tested?
Every existing declarative-config test moves verbatim into the new package (333 tests, all passing, including the new #5311 tests for the file exporter). The SDK suite (804 tests) passes, with the routing test rewritten to patch the new module paths and cover the missing-package case. Ruff + format clean across both packages.
Does This PR Require a Contrib Repo Change?
Checklist: