Proposal: avoid unsupported TorchScript on Python 3.14 - #1406
Conversation
|
I have read the CLA Document and I sign the CLA. |
49e08c1 to
ae91778
Compare
There was a problem hiding this comment.
Pull request overview
This PR makes RF-DETR’s top-level import compatible with Python 3.14+ by avoiding module-import-time TorchScript compilation (torch.jit.script), while keeping the existing scripted aliases on currently supported Python versions.
Changes:
- Add a Python-version-gated eager fallback for the four import-time TorchScripted loss helpers in
box_ops.pyandcriterion.py. - Add a subprocess regression test that fails if a
torch.jit.scriptdeprecation warning is emitted duringimport rfdetr. - Expand CPU CI to include Python 3.14 and update package/documentation metadata to advertise 3.14 support.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| tests/utilities/test_package.py | Adds an import-time warning-as-error subprocess regression test for torch.jit.script. |
| src/rfdetr/utilities/box_ops.py | Avoids torch.jit.script at import time on Python 3.14+ via eager alias fallback. |
| src/rfdetr/models/criterion.py | Avoids torch.jit.script at import time on Python 3.14+ and updates in-file commentary about the eager alias boundary. |
| pyproject.toml | Adds the Python 3.14 classifier. |
| AGENTS.md | Updates stated tested Python range and CI CPU workflow description to include 3.14. |
| .github/workflows/ci-tests-cpu.yml | Adds Python 3.14 to the Ubuntu CPU test matrix. |
| .github/CONTRIBUTING.md | Updates contributor docs to list Python 3.14 as supported/tested. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| - **Python Versions:** 3.10, 3.11, 3.12, 3.13, 3.14 | ||
| - **CPU Workflow:** `pytest -m "not gpu"` - Runs on all OS/Python combinations |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #1406 +/- ##
=======================================
- Coverage 86% 86% -0%
=======================================
Files 114 114
Lines 14880 14882 +2
=======================================
- Hits 12835 12784 -51
- Misses 2045 2098 +53 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
🟢 Approval recommended
The compatibility fallback and CI coverage are coherent; feedback is limited to minor documentation wording.
Review details
Suppressed comments (1)
.github/CONTRIBUTING.md:295
- With 3.14 now the upper supported version, “boundary versions” implies that Windows and macOS also test 3.14, but the matrix includes those OSes only for 3.10 and 3.13. Please name the exact versions here (or add 3.14 jobs) so the contributor documentation matches the workflow.
- **ci-tests-cpu.yml** — CPU tests on Ubuntu across Python 3.10–3.14, plus Windows and macOS boundary versions
- Files reviewed: 7/7 changed files
- Comments generated: 1
- Review effort level: Balanced
| GitHub Actions workflows in `.github/workflows/`: | ||
|
|
||
| - **ci-tests-cpu.yml:** CPU tests across OS/Python versions | ||
| - **ci-tests-cpu.yml:** CPU tests on Linux across Python 3.10-3.14, plus Windows and macOS boundary versions |
Hi! While checking RF-DETR on Python 3.14, I saw this warning during a normal top-level import with PyTorch 2.13:
Would you be interested in handling it with the conditional eager fallback proposed here?
Evidence
Importing
rfdetrexecutes four module-leveltorch.jit.scriptcalls:batch_dice_lossandbatch_sigmoid_ce_lossdice_lossandsigmoid_ce_lossWith the warning promoted to an error, current
developstops at the first site:The existing dependency-resolution matrix includes Python 3.14, but it only performs an install-plan dry run. The executable CPU test matrix currently stops at Python 3.13, so it cannot observe an import-time warning. A fresh install using the CPU workflow's command currently resolves PyTorch 2.13 and reproduces it.
Proposed behavior
This does not appear to be a performance issue at import time: seven fresh-process imports were effectively unchanged (1.982 s vs. 1.970 s median), and the four top-level scripting calls accounted for roughly 8 ms. A small CPU loss microbenchmark also showed identical outputs and only microseconds of eager overhead (Dice: 21.9 vs. 20.0 µs; sigmoid CE: 44.8 vs. 44.7 µs). The motivation is avoiding an explicitly unsupported path before it becomes a failure.
Validation
developatbox_ops.py:210.pre-commit run --all-filespassed in the documented Python 3.10 tooling environment.Would this conditional eager fallback be the compatibility policy you prefer, or would you rather remove or replace these TorchScript aliases more broadly?