Env variable vs code - precedence

[cijothomas]

Related to #3929 which is proposing to make ENV variable support RECOMMENDED, and not optional.

I'd like to also ask if spec would make a recommendation on order of precedence when something is specified programmatically and Env variable.

For example:
Pseudo Code:
var exporter. = new OTLPExporter();
exporter.EndPoint = "http://endpoint-from-code"

ENV Variable specifies endpoint as "http://endpoint-from-env"

Which one should the application respect? The one from CODE or the one from ENV variable? Based on my exploration, each language follows its own way and there is no consistency here.

(I'll try to find any prior discussions on this and add here)

[Aneurysm9]

We discussed this previously with respect to resource attribute precedence, but did not come to a definite conclusion.

[pellared]

In Go the code has precedence over env vars in most of the cases. In think that it offers more fine-grained control.

In "options" configuration code has precedence over env vars. E.g. https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp#WithEndpoint

For "auto" packages the env var is used and accepts a default value which is used when env var is not set: https://pkg.go.dev/go.opentelemetry.io/contrib/propagators/autoprop#NewTextMapPropagator. But one can say that this a special API which is designed explicitly to support env vars. If users does not want to support env var, they simply do not use the "auto" package.

In my opinion, this makes Go to favor code over env vars.

[jack-berg]

In java code has precedence. In fact, env variables are completely ignored unless you use a dedicated autoconfigure package.

[cijothomas]

Languages that treat explicit code config as higher precedence than ENV

1. Java
2. .NET
3. JS
4. Go
5. Python
6. // TODO fill this (Cijo to fill this)

Language that treat ENV variable as higher precedence

1. Rust. (Rust made this change recently only, and is still inconsistent, and also NOT stable, so can change to be in-line with majority)
2. C++

[tsloughter]

Erlang/Elixir is a third way. Configuration is one of the first things the SDK constructs on boot. It is built from both environment variables and Erlang's Application environment (sys.config), here the environment variables take precedence. Then each part of the SDK, like a Tracer Provider are started and passed the resolved configuration map (the merger of OS environment and Application environment). If a user starts a Provider through code they must pass this configuration map. This means they can decide which takes precedence, or if neither takes precedence and they pass a configuration map fully constructed manually.

Reading configuration on boot and not in each process when it starts is common practice. This is for cleaner code and so that configuration that can be changed at runtime is only exposed through functions/messages to the process, rather than the user being able to set new configuration with application:set_env and os:putenv followed by killing the process.

We don't expect people to ever bring SDK pieces up in code except in extreme situations, doing it through configuration means OpenTelemetry can boot fully before any other part of the program boots.

---

Eh, I suppose this is really just "code take precedence" and I could have saved a lot of your time. Since the user can either read and pass the environment configuration or not this is still done in code... so yea, code takes precedence.