feat(config): generic resource detector loading in declarative config

[MikeGoldsmith]

Currently _run_detectors() in _resource.py has a hardcoded if branch for each supported detector type. As more detectors are added, this pattern becomes repetitive.

A follow-up to generalise the loading logic — e.g. iterating over detector_config fields and loading detectors by name (including out-of-source/contrib detectors) — would make the code easier to extend.

Raised in: #5004 (comment)

[ravitheja4531-cell]

Hi, I'd like to work on this!

My plan is to replace the hardcoded if/elif branches in _run_detectors() with a generic lookup using importlib.metadata.entry_points(group="opentelemetry_resource_detector") — the same mechanism already used in Resource.create() for OTEL_EXPERIMENTAL_RESOURCE_DETECTORS. This would also naturally support contrib/out-of-source detectors (AWS, Azure, GCP, etc.) referenced by name in declarative config without requiring any SDK core changes.

Before I open a PR, a couple of questions:

1. Should the fallback for unknown detector names raise an error or silently skip (similar to how OTEL_EXPERIMENTAL_RESOURCE_DETECTORS tolerates failures per Tolerate exceptions among experimental resource detectors #4373)?
2. Are there any built-in detectors (e.g., otel) that don't have an entry point and need special-casing?

Happy to adjust the approach based on any guidance. Thanks!

[MikeGoldsmith]

Hey @ravitheja4531-cell - thanks for your support.

Regarding your questions:

• Yes, we should raise an error if an unknown detector is requested and cannot be found. Declarative config prefers fail-fast during setup as it's a configuration issue.
• all the built-in detectors (otel, host, process, os) are registered via entry points so should work with your design

We look forward to your PR 😄

[MikeGoldsmith]

Hey @ravitheja4531-cell — just checking in on this. I'm currently working through the plugin loading items on the tracking issue (#3631) and have PRs up for samplers (#5095), propagators (#5098), and exporters (#5128) which all follow the same pattern.

Since it's been a couple of weeks, I'm going to pick this one up so we can keep the plugin loading work moving together. If you'd still like to contribute, there's plenty of other items on #3631 — happy to help coordinate 😄