StartFromContext(ctx context.Context, spanName string, opts ...SpanStartOption) (context.Context, Span)

[SvenDowideit]

I'm using logr in some of my modules and code, and this lets me store the Logger inside the context, and to use it from there.

see https://pkg.go.dev/github.com/go-logr/logr#FromContext

and, this feels nice to me.

I'm very curious to know if there's something problematic about using this same idea in open-telemetry - or if not, would a PR for it be accepted?

I'm hoping that adding a NewContext(ctx, Tracer) that stores it, and a StartFromContext(ctx...) that uses it, or a NewNoopTracerProvider would be enough, and interesting, but presumably, there is scope for an additional FromContext() that either returns the set Tracer , or returns a NewNoopTracerProvider...

[dmathieu]

We store the span within the context (tracer.Start returns a context alongside the new span). And we provide methods to retrieve the current span from a context, or actually also to store a span into a specific context.
See https://github.com/open-telemetry/opentelemetry-go/blob/main/trace/context.go

As for the tracer provider (and tracer), it can be set globally:

opentelemetry-go/trace.go

Line 45 in 8423364

func SetTracerProvider(tp trace.TracerProvider) {

And retrieved from the global object.

However, changing the API to allow storing a tracer provider in the context would be a violation of the specifications. So it won't happen until that specification is changed.

There is nothing preventing you from writing your own package which stores a tracer provider within the context, and allows you to retrieve it though.

[SvenDowideit]

well wow! its not the answer i hoped for, but this is very much an example of the perfect answer to this kind of question!

Thank you for this!.

I'd love to know if there's some things I can read that provide more context as to why the specifications were written to not permit this - because that would help me decide if its sensible to make my own package to test the idea, and then if it works as i imagine, to propose a spec change, etc.

The global tracer likely achieves some of what i was wanting - and plausibly enough for most - there's always more for me to learn :)

BUT - even if there's no more breadcrumbs to follow, awesome! thank you!!

[dmathieu]

The specifications were discussed/decided using PRs. So you could use blame to find the specific PR which introduced a specific change, and go through the discussion in there.
The #otel-specification channel on the CNCF's slack could also be a good place to directly ask folks who could have more context.