Instrumentation Package depends on the OTel SDK

[NathanielRN]

Description

As a follow up to #1036, with the new configurability, the instrumentation package takes a dependency on opentelemetry.sdk because of its use in opentelemetry-instrumentation/src/opentelemetry/instrumentation/auto_instrumentation/components.py

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
  - [ ] Unit tests have been added
  - [] Documentation has been updated

[NathanielRN]

@owais Should be able to give a quick review since he has context!

[lzchen]

Isn't this a direct contradiction to this?

[NathanielRN]

@lzchen Yes I would agree that it contradicts that issue which has a valid point...

However, the opentelemetry-instrumentation package right now, and more specifically "auto instrumentation" inside of it, does depend on the opentelemetry-sdk package.

I can think of these options:

1. Keep auto instrumentation here in opentelemetry-instrumentation and mention in the docs that auto instrumentation only works for the opentelemetry-sdk TracerProvider
2. Split auto instrumentation out into opentelemetry-auto-instrumentation and make it depend on opentelemtry-instrumentation and the opentelemetry-sdk TracerProvider, which means we can validate inputs
3. Split auto instrumentation out into opentelemetry-auto-instrumentation and find the users' TracerProvider using OTEL_PYTHON_TRACER_PROVIDER so that it is generalizable, but we can't validate inputs... and it's not clear to me how we would find the classes

I think we should do 1 and then 2 as a quick follow up. If users really want 3 it shouldn't be hard to create a modification of the opentelemetry-auto-instrumentation package. (That way they can support their own custom TracerProvider auto instrumentation packages)

Please let me know what you think! Also cc @codeboten

[lzchen]

I think we should do 1 and then 2 as a quick follow up.

I agree with this.

[codeboten]

do we need the SDK at all here? couldn't we use the entrypoints defined in opentelemetry_tracer_provider and opentelemetry_exporter to determine what should be available to load for a user? I guess the one thing that we don't have a solution for is loading the resource class though.

[NathanielRN]

The point about the opentelemetry_tracer_provider is a really good point! And the Resource point is also a good call out...

I would stick by my point earlier that we don't really have to provide a 1 size fits all auto instrumentation solution. The example isn't too complicated, so I would imagine people could make their own auto instrumentation package if they really want to use another TracerProvider.

[NathanielRN]

Closing this in favor of #1415

[codeboten]

To unblock the release, i propose we merge this change and follow up with removing the dependency on the SDK in the next release

[NathanielRN]

Agreed, reopening this PR as a result of the conversion on gitter found here: https://gitter.im/open-telemetry/opentelemetry-python?at=5fbef0f82cb422778f3a1d9c

[codeboten]

Filed #1421 to track removing this dependency

[codeboten]

@lzchen please review the discussion and approve if you're ok with this plan moving of removing the dependency in the next release.