I really like this. Could you add an example of how a component could be configured using environment variables? If we can do that, then it looks like this could completely replace the existing SDK configuration code.

I understand that this is a draft, but does it make sense for the various component providers to live alongside the component and be registered (via spi) in the appropriate composer.json, rather than globally registering everything?

P.S. I'm proposing at SIG this week to soon drop 8.0 support, given its very low usage and being out of official support. That might make some further improvements possible (and I notice that spi and otel-sdk-configuration require ^8.1)

I added a configuration example that uses env substitution. We cannot fully replicate the environment variable configuration:

• variables with list/map value cannot be used, injecting YAML structures is disallowed by spec, e.g. OTEL_PROPAGATORS, OTEL_RESOURCE_ATTRIBUTES
• variables that select a specific implementation do not map to the configuration format, e.g. OTEL_TRACES_SAMPLER, OTEL_{signal}_EXPORTER
• variables with fallback behavior are not supported by the environment variable substitution definition, e.g. OTEL_EXPORTER_OTLP_{signal}_*

does it make sense for the various component providers to live alongside the component and be registered (via spi) in the appropriate composer.json, rather than globally registering everything?

I'm leaning towards yes; for extensions that are not defined by opentelemetry-configuration definitely. I mainly kept it all in a separate package for now due to the PHP8.1 requirement.

FWIW I have been using an Env\Loader interface for env configuration which could replace the current Registry + SpanExporterFactory/MetricExporterFactory etc. if we want to use the same registration mechanism for both formats.

interface Loader {

    public function load(EnvResolver $env, LoaderRegistry $registry, Context $context): mixed;

    public function name(): string;
}

I think we can merge this. Let's annotate it as experimental, and then I'll try to apply my config PR over the top.

edit: the SPI package looks nicely self-contained, but thinking about future maintainability, could the important parts of otel-sdk-configuration come into the opentelemetry org?

We should wait until #1256 is merged, I think most workflows will fail otherwise.

could the important parts of otel-sdk-configuration come into the opentelemetry org?

Yes (but it should stay independent from the SDK); should it be added to this repository?

Yes (but it should stay independent from the SDK); should it be added to this repository?

I think it should be in this repository, it doesn't feel right for a core component to depend on a contrib one. I think it can either be bundled into the Config directory, or a new one if you feel it doesn't belong in config.

#1256 has been merged, now.

Codecov Report

Attention: Patch coverage is 0% with 524 lines in your changes are missing coverage. Please review.

Project coverage is 77.24%. Comparing base (4cb0499) to head (ae980ec).
Report is 2 commits behind head on main.

@@             Coverage Diff              @@
##               main    #1249      +/-   ##
============================================
- Coverage     84.58%   77.24%   -7.35%     
- Complexity     2136     2210      +74     
============================================
  Files           284      321      +37     
  Lines          6054     6628     +574     
============================================
- Hits           5121     5120       -1     
- Misses          933     1508     +575     

@Nevay - are you still planning on working on this PR?

Could you add an example of how a component could be configured using environment variables?

open-telemetry/opentelemetry-configuration#76 provides a starter template that contains all env vars that map cleanly to file config.

are you still planning on working on this PR?

Yes; but not sure when I will find time to move otel-sdk-configuration to this repository.
Currently the packages:validate:installation check is failing: we can either copy all data from the package composer.json to the root composer.json and remove the path repository or try to fix the validation check. There are some TODOs that require SDK changes -> we should likely disable these configuration options for now. Besides that this PR should be ready for review.

Currently the packages:validate:installation check is failing

@Nevay submitted a PR against your branch which makes this command happy (per your first suggestion)