Repository navigation
test.pythoninfo fails on Windows in Azure CI #148750
Description
Bug report
Bug description:
From the logs:
.\python.exe -m test.pythoninfo
========================== Starting Command Output ===========================
"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\6b4b980f-daec-4173-8a8e-2525de58013c.cmd""
WARN: Could not find the platform standard library directory! The Python 'home' directory was set to 'D:\\a\\1\\b\\layout-embed-amd64', is this correct?
ERROR: collect_windows() failed
Traceback (most recent call last):
File "test\pythoninfo.py", line 1093, in collect_info
File "test\pythoninfo.py", line 951, in collect_windows
File "subprocess.py", line 1084, in __init__
LookupError: unknown encoding: oem
Collection failed: exit with error
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Activity
zooba commentedon Apr 20, 2026
This looks like it's unable to find/import
encodings.oemfrom a zipped stdlib (the unique aspect of the embeddable layout that's being tested here). I don't have time to dig right in right now, but hopefully that's a helpful starting point.pythongh-148750: avoid _winapi dependency leak in pythoninfo wmic codec
WARN: Could not find the platform standard library directory!#155254 as a duplicate of this issuechris-eibl commentedon Aug 11, 2026
I can reproduce the failure beginning with
3.15.0b1:I think this is related to partially freezing the encodings module: #148347
I furthermore do not think the closed duplicate #155254 is related, since this other issue started with
3.15.0a7, which can loadencodings.oem, and only issues that warning on startup:zooba commentedon Aug 17, 2026
So do we think we need to unfreeze
encodings, since it breaks zipimport of submodules? Or is there another way to solve this? (I still haven't looked yet - asking first while I catch up on everything)WARN: Could not find the platform standard library directory!#155254 as a duplicate of this issuezooba commentedon Aug 18, 2026
The frozen
encodings.__path__appears to assume that the stdlib will be on disk, I haven't quite figured out how or why (whether it's hardcoded), but it has the value even when the normalLibdirectory isn't onsys.path.Updating
encodings.__path__[:] = [f"{zip file}\\encodings"]fixes it. So it's in this__path__calculation somewhere.zooba commentedon Aug 18, 2026
Looking at the timing, I agree that #145278 is the culprit.
@FFY00 any preference between reverting the encodings freeze again or figuring out a way to fix it? It looks like your guess on one of the PRs that non-frozen submodules can't be reliably imported is the problem, and while patching
__path__is a fix, I can't see an efficient way to do that.zooba commentedon Aug 18, 2026
FTR, I have added a hack to https://github.com/python/pymanager/pull/397/changes to work around this for a PyManager update.
chris-eibl commentedon Aug 18, 2026
For the already released embeddable packages -X frozen_modules=off is a workaround:
zooba commentedon Aug 18, 2026
Yeah, but I like the startup speed 😉 It also need to be set from the initialization functions, not the command line, since we generally don't use
python.exewhen embedding.gh-148750: Unfreeze encodings module to avoid import errors with zipp…
marcelotduarte commentedon Aug 26, 2026
In cx_Freeze, I saw two options: a
__path__hack or embedding the entire encodings package. I opted for the second option.[3.15] gh-148750: Unfreeze encodings module to avoid import errors wi…
pythongh-148750: Unfreeze encodings module to avoid import errors wit…