[Packaging] Bump Python version to 3.14#33313
Conversation
️✔️AzureCLI-FullTest
|
️✔️AzureCLI-BreakingChangeTest
|
|
Thank you for your contribution! We will review the pull request and get back to you soon. |
|
The git hooks are available for azure-cli and azure-cli-extensions repos. They could help you run required checks before creating the PR. Please sync the latest code with latest dev branch (for azure-cli) or main branch (for azure-cli-extensions). pip install azdev --upgrade
azdev setup -c <your azure-cli repo path> -r <your azure-cli-extensions repo path>
|
microsoft-github-policy-service
Bot
requested review from
Pan-Qi,
bebound,
jiasli,
jsntcy,
kairu-ms,
wangzelin007 and
yonzhan
microsoft-github-policy-service
Bot
added
Packaging
act-platform-engineering-squad
CI
YangAn-microsoft
changed the title
YangAn-microsoft
changed the title
YangAn-microsoft
force-pushed
the
feature/python314-support
branch
2 times, most recently
from
986de78 to
dac4c3c
Compare
YangAn-microsoft
force-pushed
the
feature/python314-support
branch
from
333da22 to
333ad06
Compare
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
YangAn-microsoft
force-pushed
the
feature/python314-support
branch
3 times, most recently
from
b5a863b to
35c2919
Compare
YangAn-microsoft
force-pushed
the
feature/python314-support
branch
from
04daf12 to
294d9cb
Compare
AI comments: Here is a review of the comment you (@jiasli) left at #issuecomment-4496078686, along with analysis and context for each of your five points: Review of Your Comment on PR #33313Your comment raises excellent technical questions about Fix 1: the Point 1: CPython 3.14
|
| echo Installing setuptools wheel | ||
| %PYTHON_DIR%\python.exe -Im pip install setuptools wheel | ||
| if "%ARCH%"=="x86" ( | ||
| %PYTHON_DIR%\python.exe -Im pip install "setuptools<82" wheel |
There was a problem hiding this comment.
I've raise the win32 wheel issue in yaml/pyyaml#888 (comment)
Hope the wheel can be published so we don't need to change the build script.
There was a problem hiding this comment.
I agree. The solution in this PR is aiming to build pyyaml in embedded Python 3.14. Is it not necessary at all.
pyyaml only releases pyyaml-6.0.3-cp313-cp313-win32.whl (https://pypi.org/project/PyYAML/#files). pyyaml should address the absence of win32 wheel for Python 3.14.
There was a problem hiding this comment.
Replaced the previous workaround stack with a one-line ._pth fix. Now whether pyyaml provides win32 wheel won't affect our build.
Root cause (verified empirically on fresh win32 embed 3.13 vs 3.14): the old script did del python*._pth. On 3.13 that was harmless — python.exe still resolved the stdlib via default path computation. On 3.14, removing the ._pth breaks pip's PEP 517 isolated BuildEnvironment subprocess: the child python.exe can no longer locate python314.zip, fails to import encodings, and aborts in init_fs_encoding. That subprocess failure surfaced downstream as the _socket / _ctypes / setuptools.build_meta errors we'd been working around.
Fix: keep the shipped ._pth and just append import site. That single line enables site.py, which adds Lib\site-packages to sys.path. The existing pythonXY.zip / . entries keep stdlib and .pyd modules discoverable in both the parent process and any subprocess pip spawns.
Dropped: PIP_CONSTRAINT + build-constraints.txt, the setuptools<82 x86 pin, --no-build-isolation x86 branch, and the pyyaml pre-build block — all four workarounds become unnecessary because the underlying path-bootstrapping failure no longer happens.
Diff is now a single line in build.cmd:
- del python*._pth
+ for %%f in (python*._pth) do echo import site>> %%fThere was a problem hiding this comment.
Note on the 3.14 parallel-import deadlock
CPython 3.14's importlib now raises _DeadlockError on certain re-entrant module-lock acquisitions instead of silently hanging. Earlier revisions of this PR included an _prewarm_shared_imports() mitigation in azure-cli-core. That code has been dropped from this PR — #33250 (restore sequential module loading) is the correct fix and supersedes the prewarm workaround. This PR now only covers the packaging/CI move to 3.14 and the MSI build fix above; the deadlock is handled out-of-band by #33250.
YangAn-microsoft
force-pushed
the
feature/python314-support
branch
2 times, most recently
from
2c3ed95 to
863714e
Compare
YangAn-microsoft
force-pushed
the
feature/python314-support
branch
2 times, most recently
from
7d43070 to
c7e8d40
Compare
YangAn-microsoft
changed the title
Description
Bumps Azure CLI's supported Python from 3.13 → 3.14 across CI, packaging, metadata, and docs, plus one robustness fix for the Windows MSI build on the win32 embeddable Python 3.14 distribution.
Note on the 3.14 parallel-import deadlock
CPython 3.14's
importlibnow raises_DeadlockErroron certain re-entrant module-lock acquisitions instead of silently hanging. Earlier revisions of this PR included an_prewarm_shared_imports()mitigation inazure-cli-core. That code has been dropped from this PR — #33250 (restore sequential module loading) is the correct fix and supersedes the prewarm workaround. This PR now only covers the packaging/CI move to 3.14 and the MSI build fix above; the deadlock is handled out-of-band by #33250.Version bumps
azure-pipelines*.yml,breaking-change-tests.yml,regression_test.yml):versionSpec3.13 →'3.14'(quoted to preserve the trailing zero); addPython314matrix entries; addAutomationFullTestPython314ProfileLatest.Programming Language :: Python :: 3.14classifier to allsetup.pyfiles.Testing Guide
Run CI and confirm the new Python 3.14 jobs pass. The x86 MSI build exercises the embed-Python
_pthfix;test_azure_cli_installationon Linux 3.14 covers the rest of the packaging/metadata changes.History Notes
No customer-facing API changes. Internal CI, packaging, compatibility, and a Windows MSI build fix for embeddable Python 3.14.