{Packaging} Build wheels with python -m build instead of python setup.py - #33941
{Packaging} Build wheels with python -m build instead of python setup.py#33941aryasadeghi1 wants to merge 2 commits into
python -m build instead of python setup.py#33941Conversation
…tup.py` `scripts/ci/build.sh` invoked `python setup.py bdist_wheel` / `sdist` directly. Setuptools 80+ deprecates running setup.py as a CLI and warns that these calls must be removed "to avoid build errors in the future", so drive the builds through the standard PEP 517 frontend instead. `--no-isolation` preserves current behaviour: the build uses the setuptools already installed by the caller rather than provisioning a fresh one. This keeps each caller's setuptools pin in force and avoids requiring outbound network access inside the packaging test containers. `--wheel` and `--sdist` are separate invocations on purpose. A bare `python -m build` builds an sdist first and then builds the wheel from it, which would newly make MANIFEST.in correctness load-bearing. `build` is added to the four scripts that run scripts/ci/build.sh, since none of them installed the PEP 517 frontend. Verified locally: wheels produced via `python -m build --wheel --no-isolation` are identical to the previous `setup.py bdist_wheel` output for all four distributions -- same archive member list and same METADATA.
|
Hi aryasadeghi1, |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
microsoft-github-policy-service
Bot
added
Auto-Assign
There was a problem hiding this comment.
Pull request overview
This PR updates Azure CLI packaging automation to stop invoking setup.py directly (deprecated by newer setuptools) and instead build wheels/sdists via the standard PEP 517 frontend (python -m build). It also adjusts the release packaging test scripts so their container environments install the build frontend used by scripts/ci/build.sh.
Changes:
- Switch
scripts/ci/build.shfrompython setup.py bdist_wheel/sdisttopython -m build --wheel/--sdist --no-isolation. - Update RPM/AzureLinux, Debian, and Homebrew packaging test scripts to install the
buildpackage before invokingscripts/ci/build.sh. - Refresh inline comments in those scripts to reflect the new build mechanism.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| scripts/release/rpm/test_rpm_in_docker.sh | Installs build before running scripts/ci/build.sh; updates pin rationale comments. |
| scripts/release/rpm/test_azurelinux_in_docker.sh | Installs build before running scripts/ci/build.sh; updates pin rationale comments. |
| scripts/release/homebrew/test_homebrew_package.sh | Installs build alongside wheel for the packaging build step. |
| scripts/release/debian/test_deb_in_docker.sh | Installs build alongside wheel for the packaging build step. |
| scripts/ci/build.sh | Replaces setup.py CLI builds with python -m build --no-isolation for wheels and sdists. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| # --no-isolation builds against the environment prepared by the caller rather than | ||
| # provisioning a fresh one, which keeps the caller's setuptools pin in force and | ||
| # avoids requiring outbound network access inside the packaging test containers. | ||
| python -m build --wheel --no-isolation --outdir $output_dir | ||
| python -m build --sdist --no-isolation --outdir $sdist_dir |
| # Cap setuptools<81: 81 removes setup.py --dry-run and changes distutils command signatures (82 removes pkg_resources). | ||
| # scripts/ci/build.sh builds with `python -m build --no-isolation`, so this pin is the setuptools the build uses. | ||
| # `build` is the PEP 517 frontend that script invokes. |
| # scripts/ci/build.sh builds with `python -m build --no-isolation`, so this pin is the setuptools the build uses. | ||
| # `build` is the PEP 517 frontend that script invokes. | ||
| python -m pip install --upgrade "setuptools<81" build |
|
/azp run |
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
Cooper Cox (coopercox-ms)
added
the
Azure Client Tools Agent Requested
Live test skipped⏭️ Skipping the live test for this revision because no changed test file was found ( The live-test pipeline runs only the test files a PR changes, so there is nothing to execute for this commit. A skipped live test is not a passing test result. The Agent review separately checks whether the affected command module includes focused regression tests or updated recordings. If a test file is changed in a later commit, the live test will run automatically. |
![azure-client-tools-agent[bot]](https://avatars.githubusercontent.com/in/4205534?s=60&v=4){kind=small}
There was a problem hiding this comment.
CI Review Summary
This PR is set up for human review (Azure Client Tools Agent Requested). Live test dispatch was skipped (no test files changed by this PR), so the test result below reflects upstream CI only.
Result: CI has failing checks — 4 of 64 checks failed.
Failed checks:
Azure.azure-cli— Build #20260820.31 failed (details)Azure.azure-cli (Integration Test against Profiles Python312)— failed (details)Azure.azure-cli (Integration Test against Profiles Python314)— failed (details)Azure.azure-cli (Test Extensions Loading Python314)— failed (details)
Since this PR changes the wheel-build tooling (python -m build vs python setup.py), these failures likely stem from the packaging/build pipeline itself needing to pick up the new build invocation, or from downstream extension-loading/profile tests relying on the old build artifacts layout. Please inspect the build logs above to confirm whether the packaging change needs a corresponding CI pipeline update.
A human reviewer should look at the linked logs before this is merged.
azure-client-tools-agent
Bot
added
azure-client-tools-agent
|
shall we add |
Aditya Pujara (a0x1ab)
added
Azure Client Tools Agent Requested
There was a problem hiding this comment.
CI Failures — 4 checks failed
The following CI checks failed for this PR (build #340095):
| Check | Result |
|---|---|
Azure.azure-cli (main build) |
❌ Failed — 3 errors / 4 warnings |
Integration Test against Profiles Python312 |
❌ Failed — 1 error |
Integration Test against Profiles Python314 |
❌ Failed — 1 error |
Test Extensions Loading Python314 |
❌ Failed — 1 error |
Live test: Skipped (no changed test files detected in the PR).
What to investigate
The main build failure (3 errors / 4 warnings) and the integration/extension-loading failures on Python 3.12 and 3.14 suggest that switching from python setup.py to python -m build for wheel packaging is breaking the build or test environment setup. Common causes:
python -m buildproduces wheels in a different output path or format that the pipeline's install steps don't expect.- A dependency on
setup.py-specific metadata (e.g.setup.py egg_info) thatpython -m buildno longer emits. - Incompatibility between the new build backend and the Python 3.12 / 3.14 test environments.
Please review the full Azure DevOps build logs at the link above for the exact error messages, then update the PR to address each failure.
azure-client-tools-agent
Bot
added
azure-client-tools-agent
|
🔔 Routing this PR to @Azure/act-platform-engineering-squad. |
|
aryasadeghi1 can you fix the build failures indicated by the client tools agent. Thanks! |
…/build.sh scripts/ci/artifacts.sh sources scripts/ci/build.sh, so IntegrationTestAgainstProfiles and TestExtensionsLoading run the build too. Neither installed the PEP 517 frontend, so the build failed with 'No module named build'. Add it to both jobs, and provision it from build.sh when absent so the callers that no pipeline references (test_integration.sh, test_ref_doc.sh, the Windows MSI test flow) cannot hit the same failure.
|
/azp run |
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
🤖 PR Validation — ️✔️ All clear
scripts/ci/build.shinvokedpython setup.py bdist_wheel/sdistdirectly. Setuptools 80+ deprecates running setup.py as a CLI and warns that these calls must be removed "to avoid build errors in the future", so drive the builds through the standard PEP 517 frontend instead.Verified: wheels produced via
python -m build --wheel --no-isolationare identical to the previoussetup.py bdist_wheeloutput for all four distributions; same archive member list and same METADATA.Related command
Description
Testing Guide
History Notes
[Component Name 1] BREAKING CHANGE:
az command a: Make some customer-facing breaking change[Component Name 2]
az command b: Add some customer-facing featureThis checklist is used to make sure that common guidelines for a pull request are followed.
The PR title and description has followed the guideline in Submitting Pull Requests.
I adhere to the Command Guidelines.
I adhere to the Error Handling Guidelines.