4 ms·

yes, in general the context stores request-scoped data, whether or not the logger is a request-scoped value is a grey area and to reply to sibling comment, op

yes, in general the context stores request-scoped data, whether or not the logger is a request-scoped value is a grey area and to reply to sibling comment, opentelemetry is basically a house of antipatterns, definitely do not look to it for guidance

tptacek 3y ago
I don't enjoy the otel APIs, but they are implicitly scoped; contexts are a natural place to store them.
mdaniel 3y ago
> opentelemetry is basically a house of antipatterns "Look on My Works Ye Mighty and Despair!" https://github.com/open-telemetry/opentelemetry-collector/tree/v0.80.0/cmd/builder#tldr https://github.com/open-telemetry/opentelemetry-collector/tr... -> https://github.com/open-telemetry/opentelemetry-collector-releases/blob/v0.80.0/distributions/otelcol-contrib/manifest.yaml https://github.com/open-telemetry/opentelemetry-collector-re... ... and then a reasonable person trying to load that mess into their head may ask 'err, what's the difference between go.opentelemetry.io/collector and github.com/open-telemetry/opentelemetry-collector-contrib?' $ curl -fsS go.opentelemetry.io/collector | grep go-import <meta name="go-import" content="go.opentelemetry.io/collector git https://github.com/open-telemetry/opentelemetry-collector"> Oh, I see. Thanks.
euroderf 3y ago
"The context stores request-scoped data" might be another Go-team dogma due for course correction RSN.
- preseinger 3y ago
  huh? there's no dogma involved here, it's just an observation of the properties of the type a context is created with each request, and destroyed at the end of it and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it
  - euroderf 3y ago
    In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand ? DB connections, loggers, and the like. If you really want to pass around Context's in all your API signatures then at least try to make the most of it. Are pitfalls ever actually encountered ?
    - preseinger 3y ago
      if you pass a logger to a foo as a parameter to the foo constructor, then missing a logger is a compile-time error if you pass a logger to a foo as a parameter in the request context, then missing a logger is a run-time error
      - euroderf 3y ago
        Fer sher. But a passed-by-Context logger could be used (for example) to override a library package's default (stdlib?) logger. But what is the SOP / Best Practice here ? Do many libraries have some sort of SetLogger(..) initialization call, so that loggers don't clutter the API ? Or are error returns info-(over-)loaded ?
        preseinger 3y ago
        it's pretty straightforward, everything that logs takes a logger as a dependency during construction

tptacek 3y ago

I don't enjoy the otel APIs, but they are implicitly scoped; contexts are a natural place to store them.

mdaniel 3y ago

> opentelemetry is basically a house of antipatterns "Look on My Works Ye Mighty and Despair!" https://github.com/open-telemetry/opentelemetry-collector/tree/v0.80.0/cmd/builder#tldr https://github.com/open-telemetry/opentelemetry-collector/tr... -> https://github.com/open-telemetry/opentelemetry-collector-releases/blob/v0.80.0/distributions/otelcol-contrib/manifest.yaml https://github.com/open-telemetry/opentelemetry-collector-re... ... and then a reasonable person trying to load that mess into their head may ask 'err, what's the difference between go.opentelemetry.io/collector and github.com/open-telemetry/opentelemetry-collector-contrib?' $ curl -fsS go.opentelemetry.io/collector | grep go-import <meta name="go-import" content="go.opentelemetry.io/collector git https://github.com/open-telemetry/opentelemetry-collector"> Oh, I see. Thanks.

euroderf 3y ago

"The context stores request-scoped data" might be another Go-team dogma due for course correction RSN.

preseinger 3y ago
huh? there's no dogma involved here, it's just an observation of the properties of the type a context is created with each request, and destroyed at the end of it and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it
- euroderf 3y ago
  In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand ? DB connections, loggers, and the like. If you really want to pass around Context's in all your API signatures then at least try to make the most of it. Are pitfalls ever actually encountered ?
  - preseinger 3y ago
    if you pass a logger to a foo as a parameter to the foo constructor, then missing a logger is a compile-time error if you pass a logger to a foo as a parameter in the request context, then missing a logger is a run-time error
    - euroderf 3y ago
      Fer sher. But a passed-by-Context logger could be used (for example) to override a library package's default (stdlib?) logger. But what is the SOP / Best Practice here ? Do many libraries have some sort of SetLogger(..) initialization call, so that loggers don't clutter the API ? Or are error returns info-(over-)loaded ?
      - preseinger 3y ago
        it's pretty straightforward, everything that logs takes a logger as a dependency during construction