Revert "[None][infra] Bump black and tornado (#12876)"#12894
Revert "[None][infra] Bump black and tornado (#12876)"#12894yuanjingx87 merged 2 commits intoNVIDIA:release/1.2.1from
Conversation
This reverts commit f461db0.
|
/bot run --stage-list "Build-Docker-Images" |
📝 WalkthroughWalkthroughMultiple dependency and configuration files were updated: constraint entries for Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
requirements.txt (1)
10-10: Add an explicit NumPy floor in the root requirements.Line 10 changed from a bounded modern range to
numpy<2. Even with-c constraints.txt, making the tested lower bound explicit here improves reproducibility for environments that install this file directly.Proposed change
-numpy<2 +numpy>=1.26,<2🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@requirements.txt` at line 10, The requirements line currently states "numpy<2" without a lower bound; update the root requirements entry for NumPy to include an explicit minimum (e.g., change the "numpy<2" spec to "numpy>=<tested_lower_bound>,<2>") so the file reproduces the tested lower bound outside of constraint pins—pick the concrete lower bound that matches CI/constraints.txt and replace the "numpy<2" entry accordingly.examples/models/core/gemma/requirements.txt (1)
8-8: Add an explicit NumPy lower bound for deterministic dependency resolution.Line 8 uses
numpy<2without a lower bound. The constraint files in the repository (bothconstraints.txtandexamples/constraints.txt) do not enforce a NumPy floor, so this specification could resolve to very old 1.x releases. For reproducibility, add an explicit lower bound such asnumpy>=1.26,<2.Proposed refinement
-numpy<2 +numpy>=1.26,<2🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@examples/models/core/gemma/requirements.txt` at line 8, The requirements entry "numpy<2" in examples/models/core/gemma/requirements.txt lacks a lower bound; update that requirement to an explicit range such as "numpy>=1.26,<2" to ensure deterministic, reproducible dependency resolution (replace the current "numpy<2" line with the new bounded spec).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@requirements.txt`:
- Line 73: The dependency line restricting numexpr to "<2.14.0" is too broad and
blocks the patched release; update the requirement for the package symbol
"numexpr" to allow the fixed version by replacing the constraint with either
"numexpr>=2.14.1" (preferred) or "numexpr!=2.14.0,<X.Y.Z" if you want an upper
bound, and add an inline comment referencing the issue/fix (e.g., "# WAR:
numexpr 2.14.0 incompatible with numpy.typing; fixed in 2.14.1
(https://github.com/pydata/numexpr/releases/tag/v2.14.1)") so the rationale is
preserved.
---
Nitpick comments:
In `@examples/models/core/gemma/requirements.txt`:
- Line 8: The requirements entry "numpy<2" in
examples/models/core/gemma/requirements.txt lacks a lower bound; update that
requirement to an explicit range such as "numpy>=1.26,<2" to ensure
deterministic, reproducible dependency resolution (replace the current "numpy<2"
line with the new bounded spec).
In `@requirements.txt`:
- Line 10: The requirements line currently states "numpy<2" without a lower
bound; update the root requirements entry for NumPy to include an explicit
minimum (e.g., change the "numpy<2" spec to "numpy>=<tested_lower_bound>,<2>")
so the file reproduces the tested lower bound outside of constraint pins—pick
the concrete lower bound that matches CI/constraints.txt and replace the
"numpy<2" entry accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 8ff3d7c7-6794-43b9-a5f6-2d89abd743ef
📒 Files selected for processing (5)
constraints.txtexamples/models/core/gemma/requirements.txtjenkins/current_image_tags.propertiesrequirements-dev.txtrequirements.txt
💤 Files with no reviewable changes (1)
- constraints.txt
| nvidia-cutlass-dsl==4.3.4; python_version >= "3.10" | ||
| plotly | ||
| numexpr | ||
| numexpr<2.14.0 # WAR for attempted use of nonexistent numpy.typing |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Read-only verification: inspect current numexpr usage and related comments.
set -euo pipefail
echo "== numexpr references in requirements/constraints =="
rg -n -C2 'numexpr|numpy\.typing' --glob '**/*requirements*.txt' --glob '**/*constraints*.txt'
echo
echo "== Python imports/usages =="
rg -n -C3 '\bimport numexpr\b|\bnumexpr\.' --type=pyRepository: NVIDIA/TensorRT-LLM
Length of output: 463
🌐 Web query:
Is there a documented numexpr issue or release note in/after 2.14.0 related to numpy.typing compatibility, and what is the recommended compatible version range with NumPy 1.26.x?
💡 Result:
Yes.
- Documented issue / release note: NumExpr 2.14.0 introduced “static typing support” (it imports/uses
numpy.typing).[1] In 2.14.1, the release notes explicitly say static typing support was rolled back “to ensure compatibility with NumPy 1.26” and that CI tests for NumPy 1.26 were added.[2] - Recommended NumExpr version range for NumPy 1.26.x: use numexpr ≥ 2.14.1 (and avoid 2.14.0). NumExpr 2.14.1 also sets its NumPy requirement to
numpy >= 1.26.0.[3]
Sources: [1] NumExpr 2.14.0 release notes, [2] NumExpr 2.14.1 release notes, [3] NumExpr 2.14.1 requirements.txt.
Reconsider numexpr constraint; 2.14.1+ resolves the documented issue.
The constraint numexpr<2.14.0 correctly avoids the broken 2.14.0 release but blocks fixed versions. NumExpr 2.14.0 introduced numpy.typing support (causing compatibility failures with NumPy 1.26), and 2.14.1 explicitly rolled back this feature per its release notes.
Either:
- Update to allow the fixed version:
numexpr>=2.14.1(preferred if compatible), or - Explicitly exclude only the broken version:
numexpr!=2.14.0plus a reasonable lower bound.
Document the constraint with a reference: # WAR: numexpr 2.14.0 incompatible with numpy.typing; fixed in 2.14.1 (https://github.com/pydata/numexpr/releases/tag/v2.14.1)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@requirements.txt` at line 73, The dependency line restricting numexpr to
"<2.14.0" is too broad and blocks the patched release; update the requirement
for the package symbol "numexpr" to allow the fixed version by replacing the
constraint with either "numexpr>=2.14.1" (preferred) or "numexpr!=2.14.0,<X.Y.Z"
if you want an upper bound, and add an inline comment referencing the issue/fix
(e.g., "# WAR: numexpr 2.14.0 incompatible with numpy.typing; fixed in 2.14.1
(https://github.com/pydata/numexpr/releases/tag/v2.14.1)") so the rationale is
preserved.
|
PR_Github #42549 [ run ] triggered by Bot. Commit: |
Signed-off-by: Yiteng Niu <6831097+niukuo@users.noreply.github.com>
|
/bot run |
|
PR_Github #42558 [ run ] triggered by Bot. Commit: |
3 participants
Summary by CodeRabbit
Description
Test Coverage
PR Checklist
Please review the following before submitting your PR:
PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.
PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.
Test cases are provided for new code paths (see test instructions)
Any new dependencies have been scanned for license and vulnerabilities
CODEOWNERS updated if ownership changes
Documentation updated as needed
Update tava architecture diagram if there is a significant design change in PR.
The reviewers assigned automatically/manually are appropriate for the PR.
Please check this after reviewing the above items as appropriate for this PR.
GitHub Bot Help
To see a list of available CI bot commands, please comment
/bot help.