Make auto instrumentation use the same dependency resolver as manual instrumentation does

[rjduffner]

Description

In order for the auto instrumentation to use the same dependency checker as the instrumentation itself, I introduce an exception that allows for an early exit from instrument function through the distro and back to the _load.

Fixes #3201

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Updated existing tests to handle the case of the new dependency check
• Added a new test to make sure that when a dependency conflict gets returned to the instrument function, it raises an exception.

Does This PR Require a Core Repo Change?

• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added

[rjduffner]

@xrmx, Here is an option for making the auto instrumentation use the same dependency checker as the manual instrumentation.

There are a few rough edges but I think ironing those out gets us down a path of a major rewrite pretty quickly so maybe this little PR could work.

[rjduffner]

@xrmx just checking in, have you had a chance to look at this and my responses to your comment?

[xrmx]

@xrmx just checking in, have you had a chance to look at this and my responses to your comment?

Not yet, sorry

Accident

[rjduffner]

@xrmx changelog fixed up

[rjduffner]

@emdneto,

I added some testing but stopped short of the full auto instrumentation test. I stopped short because the maintainer of kafka-python has come back and is now releasing updates again. The maintainer of kafka-python-ng is reccomending switching back to kafka-python and will be archiving kafka-python-ng soon (kafka-python-ng/kafka-python-ng#210 (comment)).

These two packages were the reason this whole bug came about. But in a future PR (very soon) I'll be back with an update to the kafka-python instrumentation so it will support py312 and removal of the kafka-python-ng part of this instrumentation.

In that vein, I don't think we need to add a test for a use case that will no longer happen here shortly.

However, i still believe this PR should be merged and pushed out as I think using the same dependency resolver everywhere is the better option long term as there is one other instrumentation that also has this same behavior.

cc @xrmx

[xrmx]

@emdneto,

I added some testing but stopped short of the full auto instrumentation test. I stopped short because the maintainer of kafka-python has come back and is now releasing updates again. The maintainer of kafka-python-ng is reccomending switching back to kafka-python and will be archiving kafka-python-ng soon (kafka-python-ng/kafka-python-ng#210 (comment)).

These two packages were the reason this whole bug came about. But in a future PR (very soon) I'll be back with an update to the kafka-python instrumentation so it will support py312 and removal of the kafka-python-ng part of this instrumentation.

In that vein, I don't think we need to add a test for a use case that will no longer happen here shortly.

However, i still believe this PR should be merged and pushed out as I think using the same dependency resolver everywhere is the better option long term as there is one other instrumentation that also has this same behavior.

cc @xrmx

psycopg2 / psycopg2-binary won't go away so we can write a test case for that

[rjduffner]

Ok ill take a look at those tomorrow... hopefully. :)

[rjduffner]

@xrmx and @emdneto, when ever you get a chance, this is ready for another look. Thank you!

[rjduffner]

@emdneto thanks for the review. Everything should be updated.

[xrmx]

LGTM but unfortunately on conflict this now reproduces open-telemetry/opentelemetry-python#4509 . I'm working on a PR to fix that

UPDATE: PR here open-telemetry/opentelemetry-python#4528

[rjduffner]

Thanks @xrmx, i can rebase once that PR gets merged.