ci: pin torch version v2#10340
Conversation
second attempt to pin the torch version to cpu only. first PR passed ci/cd but once merged started failing. it looked like the the torch versions where not being properly cleaned up between steps which might indicate a larger issue. I will use this PR to both investigate pinning the torch version and also checking on our ci health and seeing if there are other optimizations we can make.
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughUpdated Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (2 inconclusive)
✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #10340 +/- ##
=======================================
Coverage 30.22% 30.22%
=======================================
Files 1315 1315
Lines 59290 59290
Branches 8876 8876
=======================================
+ Hits 17921 17922 +1
Misses 40551 40551
+ Partials 818 817 -1
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
pyproject.toml (1)
126-138: Monitor CI caching behavior post-merge; consider infrastructure improvements.The PR description notes that the first attempt passed CI but failed post-merge due to torch versions not being cleaned up between CI steps. While this code change pins torch to an exact version (2.8.0+cpu), it does not directly fix the underlying caching or cleanup logic.
Recommendation: After this PR merges, verify that the CI/CD pipeline correctly clears or invalidates torch caches between steps (e.g.,
pip cache purgeor equivalent), or uses dependency lock files (e.g.,uv.lock) to enforce reproducibility. Otherwise, similar issues may resurface even with the pinned version.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
pyproject.toml(3 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (12)
- GitHub Check: Lint Backend / Run Mypy (3.11)
- GitHub Check: Lint Backend / Run Mypy (3.10)
- GitHub Check: Lint Backend / Run Mypy (3.12)
- GitHub Check: Lint Backend / Run Mypy (3.13)
- GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 5
- GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 3
- GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 1
- GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 4
- GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 2
- GitHub Check: Run Backend Tests / Integration Tests - Python 3.10
- GitHub Check: Run Backend Tests / LFX Tests - Python 3.10
- GitHub Check: Test Starter Templates
🔇 Additional comments (3)
pyproject.toml (3)
25-25: Verify networkx range compatibility before merging.Relaxing networkx from a pinned version (==3.4.2) to a broader range (>=3.1,<4.0.0) increases flexibility but risks compatibility issues if intermediate versions introduced breaking changes. Confirm that langflow has been tested (or is known to be compatible) with all networkx versions in the [3.1, 4.0.0) range, especially 3.1–3.3 and any patch versions after 3.4.2.
220-221: Configuration to support direct-reference torch URLs is correct.The
allow-direct-references = truesetting enables Hatch to resolve the torch direct-reference URLs (lines 126–138). This is the correct and necessary configuration for PEP 508 direct references.
126-138: The torch wheel URLs are all accessible. Now I need to verify the Python 3.14 coverage concern.I found important information about Python 3.14 support. Let me check the project's
requires-pythonconstraint in the pyproject.toml:Based on the web search results, I can now confirm the Python 3.14 situation. PyTorch 2.9.0 is the first version with Python 3.14 support (as preview), while PyTorch 2.8.0 has no Python 3.14 wheels. The gap in the review comment is valid but expected.
Now let me verify the project's actual
requires-pythonconstraint:Based on my verification, here is the rewritten review comment:
All torch wheel URLs are accessible; Python 3.14 coverage is not available in PyTorch 2.8.0.
The 12 torch direct-reference URLs all return HTTP 200 and are live. However, PyTorch 2.8.0 does not support Python 3.14; support is available only in PyTorch 2.9.0 as a preview. If your project's
requires-pythonextends to 3.14, users on that version will lack torch at install time. Confirm whether supporting Python 3.14 is intentional, and if so, consider upgrading to PyTorch 2.9.0 or newer.



second attempt to pin the torch version to cpu only.
first PR passed ci/cd but once merged started failing. it looked like the the torch versions where not being properly cleaned up between steps which might indicate a larger issue. I will use this PR to both investigate pinning the torch version and also checking on our ci health and seeing if there are other optimizations we can make.
Summary by CodeRabbit