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

@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

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

I agree with this.

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.

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.

Closing this in favor of #1415

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

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

Filed #1421 to track removing this dependency

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