guardrails-ai/guardrails

[bug] OpenTelemetry Version Pinning Dependency Conflict

Closed this issue · 4 comments

Describe the bug
The OpenTelemetry version is pinned in pyproject.toml. This is causing a direct dependency version conflict with Chainlit.

  • Can OpenTelemetry be made optional?
  • Or at least remove add "^" to the OpenTelemetry version to allow minor upgrades?

To Reproduce

poetry add chainlit
poetry add guardrails-ai

Expected behavior
The packages should be installed.

Actual behavior
Version Matching failure

Because no versions of uptrace match >1.22.0,<1.24.0 || >1.24.0,<2.0.0
 and uptrace (1.22.0) depends on opentelemetry-sdk (>=1.22,<2.0), uptrace (>=1.22.0,<1.24.0 || >1.24.0,<2.0.0) requires opentelemetry-sdk (>=1.22,<2.0).
And because uptrace (1.24.0) depends on opentelemetry-sdk (>=1.24,<2.0), uptrace (>=1.22.0,<2.0.0) requires opentelemetry-sdk (>=1.22,<2.0).
Because no versions of guardrails-ai match >0.4.3,<0.5.0
 and guardrails-ai (0.4.3) depends on opentelemetry-sdk (1.20.0), guardrails-ai (>=0.4.3,<0.5.0) requires opentelemetry-sdk (1.20.0).
Thus, guardrails-ai (>=0.4.3,<0.5.0) is incompatible with uptrace (>=1.22.0,<2.0.0).
And because chainlit (1.1.101) depends on uptrace (>=1.22.0,<2.0.0)
 and no versions of chainlit match >1.1.101,<2.0.0, guardrails-ai (>=0.4.3,<0.5.0) is incompatible with chainlit (>=1.1.101,<2.0.0).
So, because data-copilot depends on both chainlit (^1.1.101) and guardrails-ai (^0.4.3), version solving failed.

Additional context

opentelemetry-sdk = "1.20.0"

Hi @aniruddha-adhikary trying to do this today as part of 0.4.4!

I assessed this, it looks like upgrading beyond 1.20.0 breaks our python 3.8 support. Figuring out if we should wait for 0.5.0 to declare guardrails on python 3.8 EOL

@zsimjee This is addressed as part of the streaming updates for 0.4.5. We essentially unlock the version to allow for any 1.x. The version that gets installed should be determined by the python version in whatever environment is installing guardrails-ai, or if the user has the specific otel libraries already in the environment it should just use those. At first glance I no longer see any issues with newer (1.25.0) versions of otel and python 3.8; at least not in the test environments running our notebooks.