Hi everyone,
I’d like to suggest an improvement to the Windows installer regarding custom installation paths and parallel installations (of the same Python version) and an option to not register Python with Windows at all. This applies to the manual GUI installer and a script/CL installation via winget.
The Problems:
1) Currently, if a global (system/user-wide) version of Python is already installed (or wrongly uninstalled), the installer often prevents a second installation of the same version at another place.
2) Even if I specify to install locally via:
winget install --id Python.Python.3.13 -e --force --source winget –scope user –override “TargetDir=“path\to\folder” InstallAllUsers=0 PrependPath=0 Include_launcher=0 Include_pip=1 /quiet /norestart”
it still registers that Python with Windows and will block another installation at another folder. It will still show up via “winget list python” (even if the generated python folder is deleted).
The Use Case: If you distribute a local/portable/isolated application where you need a full/custom Python environment bundled inside the app folder. I know this is probably a discouraged way to do things and will be needed only in rare/nieche cases but I would still be happy to have it for my hobby level projects.
-
Why not the Embeddable Zip? The embeddable package is great, but it strips out several features (like
pip,ensurepip,tkinterand fullvenvsupport) that some application relies on. Those features can’t be easily or at all added afterwards. -
Why not the not-embeddable Zip? This probably works well enough but does not give any control of what parts are getting installed as far as I can tell.
-
Why not PyInstaller/Nuitka? I specifically do not want to compile the code into an executable. I want the Python source code to remain visible and modifiable by the end-user so they can tweak the app logic themselves.
-
Why not venv? A virtual environment relies on a (global) base interpreter. I want to ship a program that works on a machine without Python (or with a different, incompatible system Python).
-
Why not portable solutions like WinPython/Miniconda? Those options are often bloated (or no choice what parts to install) and not necessarily (quickly) updated or available via scipt installation without any user input.
-
Why not manually create a python folder and ship it with the application? This makes it harder to share an app via git because of the increased size and potential license limitations. And it would require to create that folder manually again for any version change.
-
Why not automated script installation using the .msi files? That is currently my workaround but it seems to be just a hacky solution and could easily break in the future. Moreover it needs an admin account when installing the files with
msiexec /a name.msi TARGETDIR=folder
The Proposed Solution: I would like an option in the installer (perhaps an argument like PortableDir=”Folder path” that includes other settings like InstallAllUsers=0, PrependPath=0 & Include_launcher=0) to allow installing to a specific target directory regardles of any other installation. Moreover, this should not register anything with Windows (especially PATH system variable) and therefore not block another (normal) installation of the same Python version.
Thanks for considering this!
. I wasn’t aware of this since it seems to be new and not even ChatGPT5.1 (who is a much better programmer than me, a physicist) was aware. Gemini 3 Pro managed to know.