opentelemetry-python-contrib: DependencyConflict: requested: "psycopg2 >= 2.7.3.1" but found: "None"

After upgrade opentelemetry-instrumentation-psycopg2 from 0.19b0 to 0.23b2 there was an message DependencyConflict: requested: "psycopg2 >= 2.7.3.1" but found: "None", my project dependencies do not have psycopg2, there is psycopg2-binary.

Describe your environment

  • python 3.9.6
  • django 3.2.5
  • uwsgi 2.0.19.1
  • psycopg2-binary 2.9.1
  • opentelemetry-instrumentation-psycopg2 0.23b2

Steps to reproduce install psycopg2-binary to project dependencies and opentelemetry-instrumentation-psycopg2 0.23b2, run django server using uwsgi

What is the expected behavior? no DependencyConflict message

What is the actual behavior? message DependencyConflict: requested: "psycopg2 >= 2.7.3.1" but found: "None"

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 8
  • Comments: 17 (6 by maintainers)

Most upvoted comments

Another solution to this problem - theoretically could be to make a new opentelemetry-instrumentation-psycopg2-binary package, which would import code from opentelemetry-instrumentation-psycopg2 but just advertise support for "psycopg2-binary >= 2.7.3.1" instead of `“psycopg2 >= 2.7.3.1”

I managed to make the instrumentation of psycopg2 work normally with psycopg2-binary.

via the flag, skip_dep_check=True makes opentelemetry-instrumentation-psycopg2 not perform dependency checks by adding the psycopg2 connection wrapper.

As internally in psycopg2 the psycopg2 and psycopg2-binary versions use the same python code(import, codebase, functions) and everything worked normally.

I know that using skip_dep_check=True can have some side effects if the library is not installed in the project but it was a way that worked for me.

more details in this discussion

@ocelotl Sorry for the slow response, but I got around to testing this and adding skip_dep_check=True solves our problem. I’m removing our hack and we’re back to using the main package. Thank you @MatheusGeiger!

@justmobilize “package2=1.0|package2-binary=1.0” < this is not something supported by pip out of the box right? So you are proposing a syntax to denote OR? That could work but I feel if one string/element always represented a single package, it’d be so much easier to work with. How about this:

_instruments = Collection[Collection[Package...]...]

Inner tuples would be AND’ed while outer ones would be OR’ed. For example:

_instruments = (('a', 'b',), ('c',))

would mean the instrumentation will be applied either when both a and b are found or when c is found. So psycopg use case would look like

_instruments = (('psycopg2'), ('pyscopg-binary'),)

We also use psycopg-binary due to how our app is built and deployed. We are trying to figure out if we need to fork or come up with another option.

Although harder for you to maintain, instead of updating your dep resolution system, you could duplicate opentelemetry-instrumentation-psycopg2 and make opentelemetry-instrumentation-psycopg2-binary (or at least for a short term solution)

psycopg project recommends using psycopg2 in production instead of psycopg binary so we preferred to use that as the dependency.

https://www.psycopg.org/docs/install.html#psycopg-vs-psycopg-binary

For production use you are advised to use the source distribution.

If there are use cases where one might want to use the binary version, may be we can add both deps and update our dep resolution system treat such cases as OR so that presence of either library resolves the requirement.