Remove implicit dependency on TracerProvider from Tracer

[owais]

Today, the main tracer implementation accept a source argument during initialization which refers to the tracer provider instance. The tracer then stores a reference to the source (tracer provider) and uses it to access a number of different things such as sampler, resource, span processor and soon ID generator. This implicitly couples SDK tracer and tracer provider implementations. Anyone implementing a custom tracer provider must satisfy such undocumented tracer provider interface/behavior.

I propose we make all tracer dependencies explicitly to the tracer during initialization. Each dependency can be it's own argument to Tracer.__init__ or we can bundle up all such dependencies into a single object and pass that in. This will de-couple tracer and tracer provider and allow users to implement one or the other without any surprises.

discussion: #1153 (comment)

[robwknox]

@codeboten submitted PR #1295

[codeboten]

@codeboten submitted PR #1295

thanks!

[NathanielRN]

@robwknox Just wondering if in addition to @owais 's suggestion, you considered adding to the TracerProvider API.

So in opentelemetry-api/src/opentelemetry/trace/__init__.py instead of just

class TracerProvider(abc.ABC):
    @abc.abstractmethod
    def get_tracer(
        self,
        instrumenting_module_name: str,
        instrumenting_library_version: str = "",
    ) -> "Tracer":

we would have

class TracerProvider(abc.ABC):
    sampler: Sampler
    resource: Resource
    span_processor: SpanProcessor
    ids_generator: IdsGenerator

    @abc.abstractmethod
    def get_tracer(
        self,
        instrumenting_module_name: str,
        instrumenting_library_version: str = "",
    ) -> "Tracer":

I know the specifications on TracerProvider does not include these fields. However, this solution would require Custom Implementations of TracerProvider to provide these fields, which would make them compatible with the Tracer class, but which may be too restrictive to people wanting to do their own thing.

[robwknox]

@NathanielRN I like the suggestion (and it would mimic go's impl) but the snag I see is that Sampler, Resource, and SpanProcessor are only defined in the SDK so we would have to add those into the API as part of this. Is that appropriate / worthwhile?

[lzchen]

@robwknox
Sampler and SpanProcessor are purely SDK concepts so we probably don't want them in the API.

so we would have to add those into the API as part of this

How come this is the case? We already pass in these variables as part of TracerProvider without them being part of the API.

[robwknox]

@lzchen

How come this is the case? We already pass in these variables as part of TracerProvider without them being part of the API.

In order to accomplish the type hinting of the new fields @NathanielRN is suggesting for the TracerProvider API definition.