Pin ddtrace until deprecated module can be evaluated

[cswartzvi]

Recent releases of ddtrace have deprecated certain tracing modules/types (in particular Span). This causes some tests to fail (namely docs). This PR pins the ddtrace version to unblock tests until a more detailed solution can merged. For more details see: DataDog/dd-trace-py#12186.

Changes

Updated pyporject.toml to pin ddtrace to <3.0 for the datadog extra.

How I tested this

N/A

Notes

N/A

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 1ff0908 in 2 minutes and 58 seconds

More details

• Looked at 660 lines of code in 10 files
• Skipped 0 files when reviewing.
• Skipped posting 22 drafted comments based on config settings.

1. hamilton/lifecycle/api.py:376

• Draft comment:
  This class is functionally identical to BasePreTaskSubmission - it just renames pre_task_submission to run_before_task_submission while keeping the same parameters and functionality. Please use BasePreTaskSubmission directly instead.

• class BasePreTaskSubmission (base.py)

• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  While the interfaces are similar, TaskSubmissionHook serves a distinct purpose:

1. It provides a more consistent API pattern matching other hooks
2. It adds better documentation and context
3. It follows the codebase's pattern of having concrete hook implementations in api.py that inherit from base classes
4. The comment misses these important architectural aspects
   The comment does identify a surface-level similarity in the interfaces. Could there be value in reducing abstraction layers for simplicity?
   The additional abstraction layer provides important benefits in terms of API consistency, documentation, and maintainability that outweigh the minor overhead.
   The comment should be deleted as it misunderstands the architectural purpose of TaskSubmissionHook in providing a consistent concrete hook implementation pattern.

2. tests/lifecycle/test_lifecycle_adapters_end_to_end_task_based.py:121

• Draft comment:
  Consider checking the format of the run_id (e.g. using a regex for UUID) instead of asserting its length is greater than a string literal. This would make the test more robust.
• 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. tests/lifecycle/test_lifecycle_adapters_end_to_end_task_based.py:139

• Draft comment:
  In the exception test for post_node_execute hook, the acceptable number of calls is determined by a range (3 < len(...) < 9). Consider adding a comment to clarify what determines this range or refactoring the check to be more explicit if possible.
• 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.

4. tests/lifecycle/test_lifecycle_adapters_end_to_end_task_based.py:450

• Draft comment:
  The test 'test_multi_hook' uses a hard-coded Counter for hook function names. It would help future maintainers if you include a brief comment indicating why these expected counts are what they are, or if possible derive these dynamically.
• 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.

5. hamilton/execution/executors.py:410

• Draft comment:
  Using TaskImplementation as dict key relies on proper hash/eq; please ensure these are correctly defined (they appear correct in grouping.py).
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 40% <= threshold 50%
  The comment is asking the author to ensure that __hash__ and __eq__ are correctly defined for TaskImplementation. This is a request for confirmation, which violates the rule against asking the author to confirm their intention or ensure behavior. However, it does provide a specific suggestion about the use of TaskImplementation as a dict key, which could be useful if it were rephrased to focus on the correctness of the implementation rather than asking for confirmation.

6. tests/lifecycle/lifecycle_adapters_for_testing.py:50

• Draft comment:
  Global mutable 'sequence_number' may lead to issues if tests run in parallel. Consider isolating the counter per test.
• 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.

7. tests/lifecycle/test_lifecycle_adapters_end_to_end_task_based.py:121

• Draft comment:
  The assertion comparing run_id length using 'len("TODO -- add a run ID")' is unclear; consider using a more robust check.
• 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.

8. tests/lifecycle/test_lifecycle_adapters_end_to_end_task_based.py:445

• Draft comment:
  Multi-hook test: Verify that the implementations cover all lifecycle hook calls. Confirm if any hook invocations are missing.
• 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 verify and confirm if any hook invocations are missing, which violates the rule against asking the author to confirm or double-check things. It does not provide a specific suggestion or point out a specific issue.

9. hamilton/execution/executors.py:98

• Draft comment:
  Typographical error: 'diciontary' should be corrected to 'dictionary' in the docstring describing the return value of base_execute_task.
• 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.

10. hamilton/execution/grouping.py:177

• Draft comment:
  Typo: 'betweeen' should be corrected to 'between' in the docstring of the GroupByRepeatableBlocks class.
• 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.

11. hamilton/execution/grouping.py:203

• Draft comment:
  Typo: 'Fina all the Parallelizable[] nodes' should be corrected to 'Find all the Parallelizable[] nodes'.
• 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.

12. hamilton/execution/grouping.py:233

• Draft comment:
  Typo: 'In thie case of a strange override' should be corrected to 'In this case of a strange override'.
• 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.

13. hamilton/execution/grouping.py:393

• Draft comment:
  Typo: 'if we guarenteed topological order' should be corrected to 'if we guaranteed topological order' or 'if topological order is guaranteed'.
• 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.

14. hamilton/lifecycle/api.py:468

• Draft comment:
  Typographical Error: In the docstring for run_after_task_resolution in TaskResolutionHook, there's a missing space after the comma in the phrase "task executor,on". Please add a space to make it "task executor, on".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
  While the comment is technically correct about the missing space, the review rules emphasize focusing on substantive code changes and logic issues rather than minor formatting or typographical errors. This is a very minor formatting issue that doesn't impact code functionality or readability significantly.
  The comment is factually accurate. A missing space in documentation could slightly impact readability.
  While accurate, this level of nitpicking on documentation formatting doesn't meet the bar for "clearly a code change required" per the review rules. The docstring is still perfectly readable.
  The comment should be deleted as it focuses on an extremely minor typographical issue that doesn't warrant a formal review comment.

15. hamilton/lifecycle/base.py:58

• Draft comment:
  Typo detected in the comment for REGISTERED_SYNC_METHODS: the word 'metho' should be 'method'. Please update it.
• 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.

16. hamilton/lifecycle/base.py:286

• Draft comment:
  Typographical error in the docstring: 'maches' should be fixed to 'matches'.
• 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.

17. pyproject.toml:206

• Draft comment:
  There's a minor typographical error in the comment on the Q lint rule: 'Linting rules for quites'. It might be intended to say 'Linting rules for quiet'. Please update this to fix the typo.
• 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.

18. tests/lifecycle/lifecycle_adapters_for_testing.py:53

• Draft comment:
  Typo: In the comment on line 53, "its" should be corrected to "it's" for proper grammar.
• 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.

19. tests/lifecycle/lifecycle_adapters_for_testing.py:248

• Draft comment:
  In TrackingDoRemoteExecuteHook, the type annotation for the parameter 'node' is written as "node: "node.Node"". For consistency and clarity with other parts of the code, consider using Node (imported from hamilton.node) without quotes, or standardize the usage of string literal annotations.
• 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.

20. tests/lifecycle/lifecycle_adapters_for_testing.py:283

• Draft comment:
  In TrackingValidateGraphValidator, the type annotation for the 'graph' parameter is given as "FunctionGraph" (in quotes). It would be clearer to use the imported FunctionGraph without quotes, unless a string literal for a forward reference is intended. Please standardize the type annotations.
• 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.

21. tests/lifecycle/test_lifecycle_adapters_end_to_end_task_based.py:154

• Draft comment:
  Typographical error: please change 'at lease one for the inner task that failed' to 'at least one for the inner task that failed'.
• 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.

22. tests/lifecycle/test_lifecycle_adapters_end_to_end_task_based.py:189

• Draft comment:
  Typographical error: please change 'at lease one for the inner task that failed' to 'at least one for the inner task that failed'.
• 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.

Workflow ID: wflow_pAFrPW6u96nnfPQu

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[cswartzvi]

Sorry about the force push, accidentally created the branch from another PR 🤦🏻

[skrawcz]

@cswartzvi nice - I had 22509fd - mind adding a comment in h_ddog.py about it too? I can then rebase off of this and remove my one as my PR needs a little work.

[cswartzvi]

@skrawcz sure thing!