Windows 11 - No python packages are being downloaded for installation.

[SLMaxwell]

Install source and version

• Installed from the Windows Store
• Installed with the MSIX from python.org
• Installed with the MSI from python.org
• Installed with winget install 9NQ7512CXL7T

Version: 26.1.240.0

Describe the bug
It appears as if no Python packages are being downloaded for installation.

Initial installation of manager through winget appeared to complete correctly. Typing py install --configure in Windows Terminal correctly started the configuration flow. All configuration questions were accepted and configuration appeared to complete successfully. When asked to Install CPython now? answer Y.

Echo displays Installing Python 3.14.4. But then the terminal sits with no progress, no apparent network activity and no installation.

The only package that does install is the fallback package 3.14.3 bundled within the package itself. But even then only when explicitly asked for: py install 3.14.3

To Reproduce
Steps to reproduce the behavior:

1. py install (choose any version)
2. wait....

Expected behavior
Expecting a package to download and install with progress display.

Not sure what else to try for debugging to resolve or help resolve the issue?

Additional Info

• All install logs during the "freeze" are blank (0 kb) log files.
• Windows 11 Pro for Workstations Version 10.0.26200 Build 26200

[zooba]

If you run py install -vv ... then it should print the log to the console, which may help if you're blocked from writing files into %TEMP% for some reason. Hopefully it gets a bit more output, which will help narrow things down.

It's possible that something is running it constantly in the background that's blocking other instances - for obvious reasons, we don't let multiple instances of the installer operate at the same time, so if something has gotten one stuck then it could relate to that.

I'm most suspicious of the log files being empty, though. That shouldn't happen even if they get blocked by the global mutex. Running with -vv (or set PYMANAGER_DEBUG environment variable to 1) should get more info.

[MiniFlames]

Having the same issue, installer hangs at the Installing Python <VERSION> step and the log file is empty.

terminal output with the -vv flag is as follows

Loading configuration from C:\Program Files\WindowsApps\PythonSoftwareFoundation.PythonManager_26.1.240.0_x64__3847v3x7pw1km\pymanager.json
# Setting config install to {'fallback_source': 'file:///C:/Program Files/WindowsApps/PythonSoftwareFoundation.PythonManager_26.1.240.0_x64__3847v3x7pw1km/bundled/fallback-index.json', 'default_install_tag': '3'}
# Setting config list to {}
# Setting config registry_override_key to 'HKEY_LOCAL_MACHINE\\Software\\Policies\\Python\\PyManager'
# Setting config shebang_can_run_anything_silently to False
# Setting config install_dir to C:\Users\RedFlames\AppData\Local\Python
# Setting config download_dir to C:\Users\RedFlames\AppData\Local\Python\_cache
# Setting config global_dir to C:\Users\RedFlames\AppData\Local\Python\bin
# Setting config bundled_dir to C:\Program Files\WindowsApps\PythonSoftwareFoundation.PythonManager_26.1.240.0_x64__3847v3x7pw1km\bundled
# Setting config user_config to C:\Users\RedFlames\AppData\Roaming\Python\PyManager.json
# Setting config pep514_root to 'HKEY_CURRENT_USER\\Software\\Python'
# Setting config start_folder to 'Python'
# Setting config launcher_exe to C:\Program Files\WindowsApps\PythonSoftwareFoundation.PythonManager_26.1.240.0_x64__3847v3x7pw1km\templates\launcher.exe
# Setting config launcherw_exe to C:\Program Files\WindowsApps\PythonSoftwareFoundation.PythonManager_26.1.240.0_x64__3847v3x7pw1km\templates\launcherw.exe
# Setting config welcome_on_update to True
# Setting config _config_files to C:\Program Files\WindowsApps\PythonSoftwareFoundation.PythonManager_26.1.240.0_x64__3847v3x7pw1km\pymanager.json
Skipping configuration at C:\Users\RedFlames\AppData\Roaming\Python\PyManager.json because it does not exist
# Get CPU architecture, its prefix is -64
# Overriding command option fallback_source with 'file:///C:/Program Files/WindowsApps/PythonSoftwareFoundation.PythonManager_26.1.240.0_x64__3847v3x7pw1km/bundled/fallback-index.json'
# Overriding command option default_install_tag with '3'
# Finished processing options for install
Writing logs to C:\Users\REDFLA~1\AppData\Local\Temp\python_install_20260429192217_23052.log
Python installation manager 26.1
Copyright (c) Python Software Foundation. All Rights Reserved.

# BEGIN install_command.execute: ['3.13']
# Reading installs from C:\Users\RedFlames\AppData\Local\Python
# Found 0 installs
# Calculating default install
# Filtering installs by tag = 3
# tag '3' matched 0 installs
# default_platform '-64' matched 0 installs
# Reusing unfiltered list
# Searching https://www.python.org/ftp/python/index-windows.json
Searching for Python matching 3.13
# Selecting package with tag=3.13 and platform=-64
# Fetching: https://www.python.org/ftp/python/index-windows.json
# winhttp_urlopen: https://www.python.org/ftp/python/index-windows.json
# Finding ['3.13-64'] to install
Installing Python 3.13.13.
Tag: PythonCore\3.13-64
# Starting download package https://www.python.org/ftp/python/3.13.13/python-3.13.13-amd64.zip to C:\Users\RedFlames\AppData\Local\Python\_cache\pythoncore-3.13-64-3.13.13.zip
# _bits_urlretrieve: https://www.python.org/ftp/python/3.13.13/python-3.13.13-amd64.zip

across multiple attempts at installing multiple different versions it always hangs at the same # _bits_urlretrieve: step

[zooba]

I suspected it could be BITS - set PYMANAGER_ENABLE_BITS_DOWNLOAD=0 in your environment and it should skip it. Apparently there isn't enough logging to be able to tell why it's failing, and I'm not even sure what I'd query in that case - is it possible that this is related to a proxy server?

[MiniFlames]

I suspected it could be BITS - set PYMANAGER_ENABLE_BITS_DOWNLOAD=0 in your environment and it should skip it.

I don't use a proxy.

However I was able to get 3.13 to install with $env:PYMANAGER_ENABLE_BITS_DOWNLOAD="0" as you suggested. And now even without it set the issue with BITS seems to have resolved itself and I was able to install 3.14 normally without the flag set.

[zooba]

I guess I have to call it intermittent network issues? Possibly BITS is trying to access differently than WinHTTP (it should be, it's supposed to be more resilient and efficient for larger downloads), but if it's just hanging then there's apparently nothing we can detect to deal with it.

[SLMaxwell]

Thanks for the information and suggestion about setting $env:PYMANAGER_ENABLE_BITS_DOWNLOAD="0"!

My -vv output was the same as @MiniFlames.

Reviewing $env:PYMANAGER_ENABLE_BITS_DOWNLOAD returned nothing so PYMANAGER_ENABLE_BITS_DOWNLOAD is undefined/nonexistent.

I set the variable manually to "0" in the running instance of terminal and the requested 3.14.4 installation downloaded and properly applied!

Relaunching terminal so the environment variable PYMANAGER_ENABLE_BITS_DOWNLOAD was again no longer present nor defined, an attempt to install 3.13 failed at the same point in the flow:

.
.
.
# Get CPU architecture, its prefix is -64
# Overriding command option fallback_source with 'file:///C:/Program Files/WindowsApps/PythonSoftwareFoundation.PythonManager_26.1.240.0_x64__qbz5n2kfra8p0/bundled/fallback-index.json'
# Overriding command option default_install_tag with '3'
# Finished processing options for install
Writing logs to C:\Users\Scott\AppData\Local\Temp\python_install_20260430092736_24452.log
Python installation manager 26.1
Copyright (c) Python Software Foundation. All Rights Reserved.

# BEGIN install_command.execute: ['3.13']
.
.
.
Installing Python 3.13.13.
Tag: PythonCore\3.13-64
# Starting download package https://www.python.org/ftp/python/3.13.13/python-3.13.13-amd64.zip to C:\Users\Scott\AppData\Local\Python\_cache\pythoncore-3.13-64-3.13.13.zip
# _bits_urlretrieve: https://www.python.org/ftp/python/3.13.13/python-3.13.13-amd64.zip

As before, the python_install_20260430092736_24452.log file, was created in %Temp% but was again 0kb.

Manually setting the environment variable again in the newly launched terminal instance allowed 3.13.13 to download and extract properly, AND the log for this installation contained a proper listing.

Last Questions:

1. Where should the env variable PYMANAGER_ENABLE_BITS_DOWNLOAD be defined for proper terminal permanence?
   • In the System Environment variables or elsewhere?
2. Are there other Python env variables that the Install Manager should be aware of that might also be missing?

Regardless - thank you both for pointing to at least the root cause of the downloads not occurring!

I too do not use a proxy.

[zooba]

It's not missing, it just isn't meant to be defined by default. It's in there for troubleshooting (like this), and as a workaround for situations like yours where the OS's BITS component isn't working for you.

Setting as a system environment variable is fine. No other apps should be paying any attention to it.