Currently, the only way for custom Configurators to configure is through setting or defaulting environment variables. While it makes sense for customers to configure autoinstrumentation with env vars, there is no reason Configurators should not be able to directly configure start up (exporters, samplers...etc). Exposing autoinstrumentation configuration of otel via env var defaults is invasive, confusing, and easy for users to mess up. For instance, even a blank env var or a left-over setting from previous run could interfere with a distro starting up.
In this approach, configurators can pass kwargs to _initialize_components to easily configure autoinstrumentation which currently only considers env vars.
Precedence of params over env vars
Params would be preferred over (or merged with) env vars. This follows the approach towards env vars elsewhere in OTel Python. And doing so would be necessary for custom distros to guarantee certain behavior.
In this approach, exporters given by params would be ADDED to those from env vars. Resource attributes would be merged with those from env vars and resource detectors. Since there's only 1 sampler, param would take precedence. Same for logging_enabled.
Description
Currently, the only way for custom Configurators to configure is through setting or defaulting environment variables. While it makes sense for customers to configure autoinstrumentation with env vars, there is no reason Configurators should not be able to directly configure start up (exporters, samplers...etc). Exposing autoinstrumentation configuration of otel via env var defaults is invasive, confusing, and easy for users to mess up. For instance, even a blank env var or a left-over setting from previous run could interfere with a distro starting up.
In this approach, configurators can pass kwargs to _initialize_components to easily configure autoinstrumentation which currently only considers env vars.
Precedence of params over env vars
Params would be preferred over (or merged with) env vars. This follows the approach towards env vars elsewhere in OTel Python. And doing so would be necessary for custom distros to guarantee certain behavior.
In this approach, exporters given by params would be ADDED to those from env vars. Resource attributes would be merged with those from env vars and resource detectors. Since there's only 1 sampler, param would take precedence. Same for logging_enabled.