{packaging} enable site in python._pth instead of deleting it#33419
{packaging} enable site in python._pth instead of deleting it#33419YangAn-microsoft wants to merge 1 commit into
Conversation
️✔️AzureCLI-FullTest
|
|
Hi @YangAn-microsoft, |
️✔️AzureCLI-BreakingChangeTest
|
microsoft-github-policy-service
Bot
requested review from
jiasli,
jsntcy,
wangzelin007 and
yonzhan
|
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>
|
YangAn-microsoft
changed the title
| REM than deleting it) because on Python 3.14+ removing it breaks pip's | ||
| REM PEP 517 isolated BuildEnvironment subprocess: the child python.exe | ||
| REM can no longer locate the stdlib zip and dies in init_fs_encoding | ||
| REM with ModuleNotFoundError: No module named 'encodings'. |
There was a problem hiding this comment.
Could you find evidence that Python 3.14 specifically changed the behavior when _pth file is deleted?
The del python*._pth logic was there since long ago as a manual process and was added to build.cmd in #21746 (comment).
There was a problem hiding this comment.
No there isn't a specific change introduced by Python 3.14 that caused the issue. In fact, only Python 3.14 win32 embedded has trouble importing from python*.zip.
I came up with this fix after experimenting the official way of enabling site packages for embedded python. (https://docs.python.org/3/using/windows.html#finding-modules)
Since this solves the win32 issue and using a more officially recommended solution than existing del python*._pth, I believe it's a proper change.
3 participants
Description
Replace
del python*._pthwith an idempotent append ofimport siteto the embedded Python's._pthfile in the Windows MSI build pipeline.Motivation
The embedded Python distribution ships with a
python<XY>._pthfile that, when present, switches the interpreter into isolated mode:site.pyis not imported automatically andsys.pathis taken solely from the._pthcontents. The long-standing workaround inbuild.cmdwas to delete the file so the default initialization (includingsite.py, which addsLib\site-packages) would run.That trick stops working on Python 3.14+. With no
._pthpresent, pip's PEP 517 isolatedBuildEnvironmentspawns a childpython.exethat can no longer locate the stdlib zip and dies very early ininit_fs_encodingwith:Keeping an explicit
._pthmakes the stdlib zip andLib\site-packagesdiscoverable in both the parent interpreter and any spawned subprocess. Appendingimport siteis the documented way to keep._pthwhile still runningsite.pyat startup (see Python docs — Finding modules).Notes on the implementation:
if exist python*._pth (...)guards against the cmd-shell quirk where aforover a non-matching glob would otherwise iterate the literal token.findstr /x "import site" ... >nul || echo import site>> %%fmakes the append idempotent — re-running the script (e.g. on a cached%PYTHON_DIR%) won't keep duplicating the line.Compatibility
site.pyruns,Lib\site-packagesis onsys.path, pip works.Testing
pip install,pip wheel, andazCLI invocation all work as before.encodingserror; with this change, builds succeed end-to-end.Relationship to PR #33313
PR #33313 (
feature/python314-support) ships the full Python 3.14 upgrade and depends on this fix on Windows. Extracting the_pthchange into this standalone PR keeps the fix reviewable on its own and lets it land first — it is already correct against the current Python 3.13 embedded build and is required by #33313.History notes
N/A