Skip to content

Add get_dist_dependency_conflicts back to opentelemetry-instrumentation #3418

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

emdneto
Copy link
Member

@emdneto emdneto commented Apr 10, 2025

Description

Closes #3415

@emdneto emdneto requested a review from a team as a code owner April 10, 2025 21:42
@aabmass
Copy link
Member

aabmass commented Apr 10, 2025

Needs changelog as well

@jeremydvoss
Copy link
Contributor

azure-monitor-opentelemetry==1.6.7 was changed to use the new dependency system instead of this. So, that package no longer needs this. However, I am still open to adding this back in since I don't think it should have been removed. We can discuss in the SIG.

@jeremydvoss
Copy link
Contributor

Additional note, I realized our Azure Auto-Instrumentation would really benefit from having this back as well. There are scenarios where you may want to check whether a library is installed separate from instrumenting it. Example: We want to check if DJANGO_SETTINGS_MODULE is set if and only if Django is installed. If it's not installed, there's no need. If it is installed, we want to know that BEFORE attempting to instrument Django.

#677

@jeremydvoss jeremydvoss reopened this Apr 14, 2025
@jeremydvoss
Copy link
Contributor

Further explanation for why we need this back

https://github.com/open-telemetry/opentelemetry-python-contrib/pull/3202/files#diff-987664d3e7c7e52d7ab347c3c564586428dbf4b2471847edae1517ca2248f17b:~:text=(conflict)-,_LOG.error(conflict),-if%20raise_exception_on_conflict%3A

With the new approach, there will always be an ERROR log whenever there is a dependency conflict. So, running autoinstrumentation now produces tons of instrumented error logs for every package not installed.

@jeremydvoss
Copy link
Contributor

jeremydvoss commented Apr 15, 2025

More support for this PR: 
Yet another issue with the breaking change, it appears completely untested.

Calling distro.load_instrumentor will generally not raise DependencyConflictError. First, load_instrumentor loads the entrypoint which will result in a ModuleNotFound error if the instruemnted library does not exist. This occurs before instrument() is even called let alone when it has the chance to raise a DependencyConflictError

@emdneto
Copy link
Member Author

emdneto commented Apr 15, 2025

@jeremydvoss About your first concern, do you have a situation as an example?

About your second concern, do you think 9c969f3 works for you?

@jeremydvoss
Copy link
Contributor

jeremydvoss commented Apr 15, 2025

@jeremydvoss About your first concern, do you have a situation as an example?

About your second concern, do you think 9c969f3 works for you?

No, it should not be a ModuleNotFound. It is a dependency conflict. In other words, that DependencyConflictException section does not do anything.

We could solve it by adding the dependency check to distro.load_instrument. I'll work on that as a separate PR.

) -> DependencyConflict | None:
warnings.warn(
"get_dist_dependency_conflicts is deprecated since 0.53b0 and will be removed in a future release.",
DeprecationWarning,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't add deprecation warning until we are sure of our path forward.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we discussed in slack: let's remove this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

opentelemetry-instrument 0.53b0 release breaks azure-monitor-opentelemetry
3 participants