Replace setup.py bdist_wheel with python -m build --wheel #156712
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/156712
Note: Links to docs will display an error until the docs builds have been completed. ❌ 4 New Failures, 9 PendingAs of commit b11c3ac with merge base c184cb3 ( NEW FAILURES - The following jobs have failed:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
ghstack-source-id: 21ed131 Pull Request resolved: pytorch#156712
| else | ||
| # Explicitly set USE_DISTRIBUTED=0 to align with the default build config on mac. This also serves as the sole CI config that tests | ||
| # that building with USE_DISTRIBUTED=0 works at all. See https://github.com/pytorch/pytorch/issues/86448 | ||
| USE_DISTRIBUTED=0 USE_OPENMP=1 MACOSX_DEPLOYMENT_TARGET=11.0 WERROR=1 BUILD_TEST=OFF USE_PYTORCH_METAL=1 python setup.py bdist_wheel --plat-name macosx_11_0_arm64 | ||
| USE_DISTRIBUTED=0 USE_OPENMP=1 MACOSX_DEPLOYMENT_TARGET=11.0 WERROR=1 BUILD_TEST=OFF USE_PYTORCH_METAL=1 python -m build --wheel --no-isolation -C--build-option=--plat-name=macosx_11_0_arm64 |
There was a problem hiding this comment.
FYI, build 1.3.0 was released last week, which added a new --config-json option. That might be better than --config-setting / -C.
There was a problem hiding this comment.
Thanks, that's an interesting new facility. It seems clear that we could move to --config-json="{'--build-option': '--platform-name=macosx_11_0_arm64'}", but given the support in setuptools, I am afraid we can't go all the way to --config-json="{'build-option': {'platform-name': 'macosx_11_0_arm64'}}". With the lack of support in older build versions, I think the best way forward is to stick with --config-setting for now and to reevaluate with a larger build system overhaul.
| @@ -10,6 +10,11 @@ boto3==1.35.42 | |||
| #Pinned versions: 1.19.12, 1.16.34 | |||
| #test that import: | |||
|
|
|||
| build | |||
There was a problem hiding this comment.
| build | |
| build==1.3.0 |
There was a problem hiding this comment.
As long as we stick with --config-setting/-C, I think we can leave this pin open.
There was a problem hiding this comment.
It is used to keep our CI reproducible.
There was a problem hiding this comment.
That makes sense and I have no objection to pinning. However, not all packages in the file are pinned, c.f. click, psutil, pyyaml, and others. How is it decided which ones to pin and which ones to leave open? And when should the actual pin deviate from the comment as with fbscribelogger and others?
Previously we already replaced most use of
python setup.py develop/install.This PR also replaces the use of
setup.py bdist_wheelwith the modernpython -m build --wheelalternative.Stack from ghstack (oldest at bottom):