Skip to content

[build] pin setuptools>=77 to enable PEP 639 #158104

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 44 commits into
base: gh/XuehaiPan/365/base
Choose a base branch
from

Conversation

XuehaiPan
Copy link
Collaborator

@XuehaiPan XuehaiPan commented Jul 11, 2025

PEP 639: peps.python.org/pep-0639

setuptools v77 adds PEP 639 support for SPDX expression as package.license in pyproject.toml and also deprecated TOML-table-based package.license. That depression will be converted to an error in the future.

Note that setuptools<77 does not support SPDX-based package.license while setuptools>=77 will error for non-SPDX-based package.license in the future. We need an explicit version pin for setuptools>=77 (or pin setuptools<77).

See also:

Stack from ghstack (oldest at bottom):

cc @malfet @seemethere @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @chauhang @amjames @Lucaskabela

[ghstack-poisoned]
@XuehaiPan XuehaiPan requested review from a team and jeffdaily as code owners July 11, 2025 05:53
Copy link

pytorch-bot bot commented Jul 11, 2025

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/158104

Note: Links to docs will display an error until the docs builds have been completed.

❌ 9 New Failures, 2 Cancelled Jobs, 16 Pending, 1 Unrelated Failure

As of commit 75c8c6c with merge base b219ca2 (image):

NEW FAILURES - The following jobs have failed:

CANCELLED JOBS - The following jobs were cancelled. Please retry:

FLAKY - The following job failed but was likely due to flakiness present on trunk:

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[ghstack-poisoned]
[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Jul 11, 2025
[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Jul 11, 2025
[ghstack-poisoned]
XuehaiPan added a commit that referenced this pull request Jul 11, 2025
[ghstack-poisoned]
@XuehaiPan XuehaiPan added module: build Build system issues release notes: build release notes category topic: build labels Jul 11, 2025
XuehaiPan added a commit that referenced this pull request Jul 11, 2025
@XuehaiPan XuehaiPan marked this pull request as ready for review July 11, 2025 10:17
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Jul 31, 2025
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 5, 2025
@iremyux
Copy link
Collaborator

iremyux commented Aug 6, 2025

Adding ciflow/win-arm64 label to trigger Windows Arm64 CI and its test purposes - nothing about this PR specifically. (It should not effect the acceptance of the PR even if it fails.)

@iremyux iremyux added the ciflow/win-arm64 Trigger Windows Arm64 CI Workflows label Aug 6, 2025
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 6, 2025
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 10, 2025
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 11, 2025
@XuehaiPan
Copy link
Collaborator Author

Since PyTorch 2.8.0 has been released, I wonder if there are any blockers or unresolved concerns about this PR? cc @albanD

@albanD
Copy link
Collaborator

albanD commented Aug 11, 2025

To me there are two main concers:

  • I don't understand what we need from pep 639 that justifies all of this.
  • A lot of version updates and pinning that I'm not sure how to check clearly.

@XuehaiPan
Copy link
Collaborator Author

To me there are two main concers:

  • I don't understand what we need from pep 639 that justifies all of this.

See the PR description #158104 (comment), we will need to pin either <77.0 or >=77.0 shortly. Otherwise, setuptools will complain and fail.

  • A lot of version updates and pinning that I'm not sure how to check clearly.

I will try to remove the pins as much as I can in this PR, and then get back to you.

[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 12, 2025
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 12, 2025
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 12, 2025
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 12, 2025
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 12, 2025
[ghstack-poisoned]
XuehaiPan added a commit to XuehaiPan/pytorch that referenced this pull request Aug 12, 2025
Copy link
Collaborator

@albanD albanD left a comment

Choose a reason for hiding this comment

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

I would like to get someone from Infra, either @atalman or @seemethere or @malfet comment on adding a new "pip install -r requirements-build.txt" to all the build/test scripts. It feels to me like these are at least partially redundant and we should remove whatever is trying (and failing) to install these dependencies if we're adding this now.

Also a couple nits to keep everything <80 to avoid changing the build frontend between easy_install and pip.

@@ -16,7 +17,7 @@ if "%DESIRED_PYTHON%" == "3.9" %PYTHON_EXEC% -m pip install numpy==2.0.2 cmake

%PYTHON_EXEC% -m pip install pyyaml
%PYTHON_EXEC% -m pip install mkl-include mkl-static
%PYTHON_EXEC% -m pip install boto3 ninja typing_extensions setuptools==72.1.0
%PYTHON_EXEC% -m pip install boto3 ninja typing-extensions setuptools packaging
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why not use the requirements-build.txt file for this one?

@@ -26,7 +26,7 @@ pytest-xdist==3.3.1
pytest==7.3.2
pyyaml==6.0.2
scipy==1.12.0
setuptools==72.1.0
setuptools==80.9.0
Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's keep it <80

# 77.0.0: min version for SPDX expression support for project.license
"setuptools>=70.1.0,<80.0",
"setuptools>=77.0.0,<80.0",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Aren't these duplicate of requirements-build.txt? Can we remove one of the two?

Copy link
Contributor

@malfet malfet left a comment

Choose a reason for hiding this comment

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

It feels like we have an explosion of requirements-something-or-other files in PyTorch repo

May be before we start relying using another one, propose a separate PR that adds comment to each of them explaining when they should vs should not be used

Also, at least for linux, to avoid waisting CI resources, all requirements should be installed as part of the container setup, defined here: .ci/docker/requirements-ci.txt

@malfet
Copy link
Contributor

malfet commented Aug 12, 2025

And I know it's way too late to complain, but I'm confused about the purpose of #158111

Requirements should be installed once, if we need custom test configs that lower or raise versions, it should be done differently

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci-no-td Do not run TD on this PR ci-test-showlocals Show local variables on test failures ciflow/binaries Trigger all binary build and upload jobs on the PR ciflow/inductor ciflow/nightly Trigger all jobs we run nightly (nightly.yml) ciflow/trunk Trigger trunk jobs on your pull request ciflow/win-arm64 Trigger Windows Arm64 CI Workflows keep-going Don't stop on first failure, keep running tests until the end Merged module: build Build system issues module: dynamo open source release notes: build release notes category release notes: quantization release notes category release notes: releng release notes category Reverted topic: build
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[CI] Inductor-perf-nighly-macos started to fail to install torchvision
10 participants