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.

[xrmx]

Any reason why you are removing this cache? I'm not sure this cache really helps with anything :)

[rjduffner]

When I removed line 103 below, I couldn't find any other usages of this class so I removed this class just to keep things tidy.

If I missed a usage or a use case somewhere I am happy to re-add it. I just pulled it since my code search told me it was dead code.

[rjduffner]

I actually think get_dist_dependency_conflicts is now unused too

> ag get_dist_dependency_conflicts
opentelemetry-instrumentation/tests/test_dependencies.py
23:    get_dist_dependency_conflicts,
68:    def test_get_dist_dependency_conflicts(self):
82:        conflict = get_dist_dependency_conflicts(dist)
90:    def test_get_dist_dependency_conflicts_requires_none(self):
103:        conflict = get_dist_dependency_conflicts(dist)

opentelemetry-instrumentation/src/opentelemetry/instrumentation/dependencies.py
51:def get_dist_dependency_conflicts(

CHANGELOG.md
64:- `opentelemetry-instrumentation` Fix `get_dist_dependency_conflicts` if no distribution requires

[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

[emdneto]

I understand this is deleted because we don't need get_dist_dependency_conflicts anymore. or is there other any reason?

[rjduffner]

Ya the function, get_dist_dependency_conflicts has been fully removed and we no longer pull dependencies from the dist.

https://github.com/open-telemetry/opentelemetry-python-contrib/pull/3202/files#diff-fa513a8f13e9ef85e44311858ced6f35bb55b07f87f19ca27094ff82be08ae34L43-L59

[emdneto]

Would you open to write similar test to kafka since it's the instrumentation lib stated in your issue?

[rjduffner]

Ya I can work on that. I am at a company conference this week but will try to get to it next week.

[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]

@emdneto, I think i got it here.

I added some tests first to make sure that the instrumentation_dependencies functions handle both, one or none installed.

The last test, test_instruments_with_psycopg2_installed, tests higher up in the auto instrumentation flow to make sure that the individual error around one package working but not the other doesn't happen again.