Skip to content

fix(ci): Install pytorch pinned requirements in core UT workflow#6384

Open
zjliu-amd wants to merge 2 commits into
mainfrom
users/zjliu-amd/pt-core-ut-install-requirements
Open

fix(ci): Install pytorch pinned requirements in core UT workflow#6384
zjliu-amd wants to merge 2 commits into
mainfrom
users/zjliu-amd/pt-core-ut-install-requirements

Conversation

@zjliu-amd

Copy link
Copy Markdown

Motivation

PyTorch Core UT workflow only installs the requirements specified in TheRock, but not the more detailed pytorch requirements, which cause numpy version not pinned and therefore leading to UT failures. Besides, this is also causing a lot of UTs missing dependencies such as scipy. This requirements.txt file IS installed in test_pytorch_wheels_full, but not in this workflow.

@therock-pr-bot

therock-pr-bot Bot commented Jul 7, 2026

Copy link
Copy Markdown

✅ All Checks Passed — Ready for Review

Check Status Details
🌿 Branch Name ✅ Pass
📝 PR Title/Description ✅ Pass
Forbidden Files ✅ Pass
🧪 Unit Test ✅ Pass PR does not contain code files — Unit Test auto-passed
🔎 pre-commit ✅ Pass
🚫 Draft PR 🔜 To Be Enabled
🚩 Feature Flag 🔜 To Be Enabled
📊 Code Coverage 🔜 To Be Enabled
🤖 therock-pr-bot ✅ Pass

🎉 All checks passed! This PR is ready for review.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

@therock-pr-bot

therock-pr-bot Bot commented Jul 7, 2026

Copy link
Copy Markdown

🎉 All checks passed! This PR is ready for review.

@zjliu-amd zjliu-amd changed the title Install pytorch pinned requirements fix: Install pytorch pinned requirements in core UT workflow Jul 7, 2026
@zjliu-amd zjliu-amd changed the title fix: Install pytorch pinned requirements in core UT workflow fix(ci): Install pytorch pinned requirements in core UT workflow Jul 7, 2026
@HereThereBeDragons

Copy link
Copy Markdown
Contributor

similar is done in #6400

@lucbruni-amd

Copy link
Copy Markdown
Contributor

@HereThereBeDragons I'm in favour of this PR since it pulls the other missing test deps (not just numpy) thus resolving other UT issues. It also fixes the dependency drift issue and the need to pin deps. Should we close #6400 and #6423 and proceed with this one?

@ethanwee1

Copy link
Copy Markdown
Contributor

I am in favor of this move.

@HereThereBeDragons

Copy link
Copy Markdown
Contributor

yeah i think this seems more elegant. but we probably then want some comment in requirements-test.txt that for the ci testing we also use the pytorch requirements.txt and some versions may be overwritten?

@zjliu-amd

zjliu-amd commented Jul 9, 2026

Copy link
Copy Markdown
Author

This change, however, could lead to a dependency installation failure on high python versions (such as 3.14). An example is https://github.com/ROCm/TheRock/actions/runs/28899244667/job/85731743101
Some dependencies don't provide prebuilt wheels for python 3.14 in the pinned versions, which result in pip building them from source. But the compiler in the CI can't find some headers they need. Could be the same problem as actions/setup-python#489
We can possibly fix this by either pinning some dependencies to a higher version which provides python 3.14 binary, or by exporting an env var as suggested in actions/setup-python#489. There are 4 dependencies need to be built for pytorch 2.11, possibly less on 2.12 and more on 2.10 (haven't confirmed).

Update: Fixed by bumping dependency version in pytorch

@ethanwee1

Copy link
Copy Markdown
Contributor

Rather than pin an old numpy in TheRock long-term, we're going to fix this at the source and let TheRock inherit upstream's pins. Two upstream approaches are staged:

First, cap numpy in upstream test CI: Cap numpy <2.5 in requirements-ci.txt to avoid strict-cast regression by ethanwee1 · Pull Request #1… adds a <2.5 upper bound to the numpy entries in .ci/docker/requirements-ci.txt (keeping the existing floors), so CI resolves to the 2.4 line (currently 2.4.6), the last release before numpy tightened negative-int to uint8 scalar casting. Least invasive, but since the numpy change was deliberate it's only a stopgap.

Second, fix the reference itself: Fix nn.functional.threshold OpInfo reference for strict NumPy uint8 casting by ethanwee1 · Pull Requ… makes the nn.functional.threshold OpInfo test dtype-safe (non-negative fill for uint8, -9 kept for signed/float), so it survives any numpy. An upstream reviewer (rgommers) already suggested this here: nn.functional.threshold OpInfo reference raises OverflowError on unsigned dtypes with NumPy >= 2.5 ·…

Once the reference fix (option 2) is validated upstream, we'll drop TheRock's external-builds/pytorch/requirements-test.txt numpy pins entirely so we inherit upstream's requirements-ci.txt versions.

@ScottTodd ScottTodd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed that this is nicer than #6400

- name: Install test requirements
run: |
python -m pip install -r external-builds/pytorch/requirements-test.txt
python -m pip install -r external-builds/pytorch/pytorch/.ci/docker/requirements-ci.txt

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this external-builds/pytorch/pytorch directory is the default but it is not the path we use when building on Windows. Looks like we do use it here for testing consistently on both platforms though.

Comment on lines 210 to +211
python -m pip install -r external-builds/pytorch/requirements-test.txt
python -m pip install -r external-builds/pytorch/pytorch/.ci/docker/requirements-ci.txt

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this will bump the requirements install time from ~5 seconds (example: https://github.com/ROCm/TheRock/actions/runs/29119539622/job/86451121264#step:11:1) to ~1m07s (example: https://github.com/ROCm/TheRock/actions/runs/29264970035/job/86867806066#step:11:1)

If pytorch needs all of the extra packages, that's fine.

To optimize, we can look into tuning a persistent pip cache on our GPU test runners and/or switching from pip to uv.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine to me, as long as we get more stable and comprehensive dependency installation

Comment thread .github/workflows/test_pytorch_wheels.yml
@zjliu-amd

Copy link
Copy Markdown
Author

@ScottTodd There's only one thing I want to ask for your opinion: currently some of the pinned dependencies don't have prebuilt wheels for python 3.14, which is in our test matrix. If we run pip install -r requirements-ci.txt in python 3.14 workflows, it will try to build those dependencies from source. However, the build will fail because the rock CI's environment lacks some env vars or packages.
We already have a workaround in place, which is to bump dependencies version in requirements-ci.txt to a version that ships prebuilt 3.14 wheels for python 3.14 only, but this could potentially cause subtle bugs if the dependencies change their behaviour in new versions, and that would also require us to maintain requirements-ci.txt for each release branch and python version separately, instead of inheriting upstream's pin.
I'm also testing if we can update the workflow so we can build dependencies from source, here are my changes: main...users/zjliu-amd/pip-build-from-src. This should enable the pip to build from source successfully (example).
Which way do you think is a better solution, or do you have other insights? I'd like to know your opinion :)

@ScottTodd

Copy link
Copy Markdown
Member

We need to be very careful with installing system-wide -dev packages. The rocm (and torch) packages that we build and distribute are intended to be portable across multiple linux distributions and self-contained (i.e. no/minimal dependencies on libraries that must be installed separately). Installing -dev packages includes the risk of packages pulling in other -dev packages and the resulting binaries referencing system libraries. For more details see

I'd prefer to use requirements that include prebuilt wheels, and we can even host such wheels ourselves in our python package mirror repositories like https://rocm.nightlies.amd.com/whl-multi-arch/

@zjliu-amd

Copy link
Copy Markdown
Author

That makes sense. I'll update the requirements file in pytorch, then we can merge this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: TODO

Development

Successfully merging this pull request may close these issues.

5 participants