fix: instrumentation dependencies issue for google, ollama and redis

[galkleinman]

Important

Fixes instrumentation dependencies for Google, Ollama, and Redis by updating package checks and dependencies.

• Google Generative AI Instrumentation:
  • Updated instrumentation_dependencies() in GoogleGenerativeAiInstrumentor to return dependencies based on installed package (google-genai or google-generativeai).
  • Added is_package_installed() check in tracing.py to handle both google-generativeai and google-genai.
  • Split WRAPPED_METHODS into LEGACY_WRAPPED_METHODS and WRAPPED_METHODS based on package version.
• Ollama Instrumentation:
  • Updated _instruments in ollama/__init__.py to require ollama >= 0.4.0.
• Redis Instrumentation:
  • Added opentelemetry-instrumentation-redis to pyproject.toml dependencies.
• Miscellaneous:
  • Added is_package_installed() utility function in utils.py for package checks.
  • Updated init_google_generativeai_instrumentor() in tracing.py to check for both google-generativeai and google-genai.

^{This description was created by for 96c9412. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to a060925 in 1 minute and 39 seconds. Click for details.

• Reviewed 136 lines of code in 5 files
• Skipped 1 files when reviewing.
• Skipped posting 5 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. packages/opentelemetry-instrumentation-google-generativeai/opentelemetry/instrumentation/google_generativeai/__init__.py:364

• Draft comment:
  Return types from instrumentation_dependencies are inconsistent (tuple vs. list). Standardize to a single collection type for consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While technically correct that the types are inconsistent, this is a very minor style issue. Both tuples and lists are valid Collection types and the code will work correctly either way. The inconsistency doesn't impact functionality or maintainability in any meaningful way. The comment feels more like a nitpick than a valuable code improvement. The inconsistency could potentially indicate a lack of attention to detail or consistent coding standards. Standardizing on one collection type could make the code slightly more maintainable. While consistency is good, this is an extremely minor issue that doesn't affect functionality or readability in any meaningful way. The time spent changing this would be better spent on more impactful improvements. This comment should be removed as it points out an extremely minor style inconsistency that doesn't meaningfully impact the code quality or maintainability.

2. packages/opentelemetry-instrumentation-google-generativeai/opentelemetry/instrumentation/google_generativeai/utils.py:38

• Draft comment:
  Caching installed packages at module load may become stale if packages change during runtime. Consider refreshing this cache if dynamic changes are expected.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a speculative comment about a potential edge case. Package installations/uninstallations during runtime are extremely rare. The code appears to be part of an instrumentation/tracing library where absolute real-time accuracy of package detection is likely not critical. The comment doesn't suggest a clear actionable change - refreshing the cache would add complexity for minimal benefit. The comment does identify a real technical limitation. In theory, this could cause bugs if code relies on real-time package detection. While technically correct, this edge case is extremely unlikely in practice and the added complexity of handling it would likely outweigh the benefits. The simple caching approach is a reasonable tradeoff. Delete this comment as it's speculative ("if packages change") and doesn't suggest a clear, worthwhile code change given the tradeoffs involved.

3. packages/opentelemetry-instrumentation-ollama/opentelemetry/instrumentation/ollama/__init__.py:34

• Draft comment:
  Ollama dependency version updated to '>= 0.4.0, < 1'. Ensure this bump is intentional and compatible with the client library changes.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to ensure that the version bump is intentional and compatible, which violates the rule against asking the author to confirm their intention or ensure compatibility. It also relates to dependency changes, which should not be commented on unless there's a specific issue identified.

4. packages/traceloop-sdk/pyproject.toml:37

• Draft comment:
  Added opentelemetry-instrumentation-redis dependency. Confirm that the specified version (>=0.50b0) aligns with your requirements.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to confirm if the version of a dependency aligns with their requirements. This falls under the rule of not asking the author to confirm or double-check things, especially related to dependencies.

5. packages/traceloop-sdk/traceloop/sdk/tracing/tracing.py:609

• Draft comment:
  Expanded google generative instrumentation check to include 'google-genai'. This is good but verify that the precedence and behavior when both packages are installed meets expectations.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to verify the precedence and behavior when both packages are installed. This falls under asking the author to ensure behavior is intended, which is not allowed according to the rules.

Workflow ID: wflow_pk3UWcnBu5QGvC6f

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 28cd6b2 in 32 seconds. Click for details.

• Reviewed 20 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. packages/opentelemetry-instrumentation-google-generativeai/opentelemetry/instrumentation/google_generativeai/utils.py:3

• Draft comment:
  Good use of importing Optional for type clarity and compatibility.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

2. packages/opentelemetry-instrumentation-google-generativeai/opentelemetry/instrumentation/google_generativeai/utils.py:33

• Draft comment:
  Changing return type to Optional[str] improves clarity and follows common conventions.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

Workflow ID: wflow_GhALd0l0x4AHLW5r

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed e6a0cc3 in 51 seconds. Click for details.

• Reviewed 35 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. packages/opentelemetry-instrumentation-google-generativeai/opentelemetry/instrumentation/google_generativeai/__init__.py:367

• Draft comment:
  Removed extraneous whitespace after returning []. This change is purely stylistic.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

2. packages/opentelemetry-instrumentation-google-generativeai/opentelemetry/instrumentation/google_generativeai/utils.py:31

• Draft comment:
  Added extra blank lines between functions for improved readability. No functional change.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

Workflow ID: wflow_zNGkwQDOzumu8Fox

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[nirga]

I think using importlib.util.find_spec(package_name) is not None for checking this will be much quicker - just discussed it with @ronensc:
#2988

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 969ccce in 1 minute and 27 seconds. Click for details.

• Reviewed 33 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. packages/opentelemetry-instrumentation-google-generativeai/opentelemetry/instrumentation/google_generativeai/utils.py:34

• Draft comment:
  Using importlib.util.find_spec simplifies the check but may behave differently than the previous distributions-based logic. Ensure the package name matches the importable module name.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. packages/opentelemetry-instrumentation-google-generativeai/opentelemetry/instrumentation/google_generativeai/utils.py:7

• Draft comment:
  The removal of the caching mechanism (via installed_packages) eliminates extra dependency usage, but if is_package_installed is frequently called this might introduce performance overhead. Consider if caching is needed.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment raises a valid concern about performance, but several factors make me lean towards removing it: 1) We don't know the usage patterns of is_package_installed() 2) The new implementation is simpler and more direct 3) Caching could introduce staleness issues 4) The performance impact is speculative without evidence 5) The suggestion isn't concrete enough to be actionable. The performance concern could be valid in high-frequency usage scenarios. The old implementation did have a clear performance advantage for multiple calls. While true, we should trust that the authors tested their changes and found the performance acceptable for their use case. Without clear evidence of a performance problem, this is too speculative. Delete the comment. While it raises a valid theoretical concern, it's too speculative without evidence of actual performance issues, and doesn't provide concrete enough guidance to be actionable.

Workflow ID: wflow_Zu4QnAb6L6iEmDfc

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 96c9412 in 1 minute and 32 seconds. Click for details.

• Reviewed 1155 lines of code in 64 files
• Skipped 0 files when reviewing.
• Skipped posting 6 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. traceloop-sdk/pyproject.toml:27

• Draft comment:
  Note: The SDK uses python '>=3.10,<4' while most instrumentation packages use '>=3.9,<4'. Ensure this divergence is intentional.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

2. traceloop-sdk/traceloop/sdk/tracing/manual.py:13

• Draft comment:
  New LLMUsage fields ('cache_creation_input_tokens', 'cache_read_input_tokens') have been added. Consider updating documentation and usage examples if not already done.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

3. CHANGELOG.md:1

• Draft comment:
  Ensure the changelog reflects all intended fixes (Google, Ollama, and Redis instrumentation dependency issues) and links to relevant PRs.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to ensure that the changelog reflects all intended fixes and links to relevant PRs. This falls under the category of asking the author to ensure something is done, which is against the rules.

4. packages/opentelemetry-instrumentation-anthropic/opentelemetry/instrumentation/anthropic/__init__.py:19

• Draft comment:
  Typographical error: 'acount_prompt_tokens_from_request' seems to be misspelled. Should it be 'account_prompt_tokens_from_request'?
• Reason this comment was not posted:
  Comment was on unchanged code.

5. packages/opentelemetry-instrumentation-groq/pyproject.toml:14

• Draft comment:
  The repository URL in this file appears to contain a typographical error. It currently reads "openllmetry" but should likely be "opentelemetry". Please verify and update if necessary.
• Reason this comment was not posted:
  Comment was on unchanged code.

6. packages/opentelemetry-instrumentation-ollama/pyproject.toml:14

• Draft comment:
  Typo detected in the repository URL. It appears that "openllmetry" is misspelled; it should likely be "opentelemetry" to match the correct instrumentation name.
• Reason this comment was not posted:
  Comment was on unchanged code.

Workflow ID: wflow_aRq1ibaeRHrukzv6

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}