Description

a-vago

opened on Oct 5, 2026

Issue body actions

Please support fully managed Python runtimes at explicitly selected drive/path locations

The current Python Install Manager direction appears too user-profile-centric for developer workstations where software placement is intentionally controlled.

My setup deliberately keeps the Windows system SSD and the Windows user profile minimal, while development tools, SDKs, runtimes, and other large software components are installed on a separate drive under explicitly chosen paths.

What I am looking for is not merely a way to extract or manually place a Python runtime somewhere.

I am asking whether Python Install Manager can support a first-class, normally managed Python installation whose runtime location is explicitly selected by the user.

Related issue

I found the following related issue:

#226

That issue discusses Python Manager installation location, py launcher exposure, WindowsApps, %AppData%\Local\Python, and PATH behavior.

My request is related, but not the same.

The main concern here is specifically managed runtime placement: whether a Python runtime can live at a user-selected filesystem location while still remaining a normal, fully managed Python Install Manager installation.

Motivation

The current deployment model appears to reduce explicit filesystem control in several ways:

• runtime and management lifecycle are increasingly tied to Windows-managed package deployment;
• MSIX-style installation hides much of the physical deployment model behind package identity and managed locations;
• package state, aliases, caches, and management metadata may be placed under the user profile;
• there does not appear to be an equivalent of a traditional explicitly located, first-class installation;
• --target does not appear equivalent to this use case, because a target-installed runtime does not have the same normal management lifecycle afterwards.

This is not primarily an objection to MSIX itself.

The concern is the loss of explicit filesystem and drive ownership for a legitimate developer-workstation use case.

For example, I would like to be able to install Python to a location such as:

D:\Development\Python\3.14\

or another explicitly selected directory, while still retaining the normal Python Install Manager lifecycle.

Ideally, such an installation would be:

• installed to an explicitly selected drive and directory;
• fully recognized and managed by Python Install Manager;
• normally updateable through the manager;
• usable with the normal launcher and runtime-selection mechanisms;
• independent of Store/MSIX-style per-user runtime deployment;
• usable as a predictable machine-level development toolchain;
• suitable for users who intentionally keep the Windows user profile and system SSD small.

I am not asking for a one-off extracted or unmanaged runtime.

I am asking whether an explicitly located runtime can remain a first-class managed installation.

Is such a deployment mode planned or technically feasible within Python Install Manager?

If not, I would like to request that this use case be considered before the traditional Windows installer disappears completely.

Without such an option, native Windows Python becomes significantly less attractive for controlled developer environments and makes WSL/Linux the more predictable choice for this kind of setup.

AI assistance disclosure

For transparency: I used ChatGPT to help organize and polish the wording of this issue.

The underlying use case, technical concerns, observations, and requested functionality are my own. I reviewed the final text and am submitting it because it accurately represents my own experience and request.

Activity

1. a-vago

   added

   enhancementNew feature or requestNew feature or request

   on Oct 5, 2026
2. zooba commented on Oct 6, 2026

   

   zooba

   on Oct 6, 2026

   Member

   More actions

   Have you tried configuring the install_dir setting? Does that achieve what you want?

   If not, you might need to find an alternate installer that will do PEP 514 registration for its runtime. The install manager will locate and launch PEP 514 registered runtimes, though it can't update or uninstall them.
3. a-vago commented on Oct 7, 2026

   

   a-vago

   on Oct 7, 2026

   Author

   More actions

   Have you tried configuring the install_dir setting? Does that achieve what you want?

   Thank you. I think I did not state the core concern clearly enough.

   The issue is fundamentally about filesystem ownership, drive separation, and keeping development-toolchain activity away from the Windows system volume — not merely about where python.exe resides.

   I deliberately keep development tools, SDKs, runtimes, repositories, build trees, and caches on separate storage. Windows already makes this separation imperfect because the user profile remains closely tied to the system volume.

   My concern is that the newer deployment model moves even more application state, metadata, aliases, caches, and lifecycle-related management into Windows-managed per-user locations.

   There is also an architectural mismatch here: Python encourages project-level isolation through venv, while the base runtime management is becoming more strongly per-user and tied to Windows package infrastructure.

   So my question is not:

   Can I put the runtime on D:?

   It is:

   Can I keep a fully managed Python development toolchain under an explicitly controlled filesystem location, without moving more of its management state back into the Windows system/user-profile infrastructure?

   install_dir helps with runtime placement, but it does not restore the traditional deployment model.

   Likewise, an alternate installer with PEP 514 registration does not solve this, because Python Install Manager can discover such runtimes but cannot manage their update/uninstall lifecycle.

   For transparency: I used ChatGPT to help structure and phrase this reply in English. The underlying concern, experience, and requested behavior are my own, and I reviewed the text before posting it.
4. zooba commented on Oct 7, 2026

   

   zooba

   on Oct 7, 2026

   Member

   More actions

   No, the traditional deployment model is gone from the python.org releases. You may be able to find other installers that still use it, but we've moved entirely to a manager and for the sake of reliability, have chosen to use the file system as the registration rather than trying to maintain a separate database. The only runtimes that can be managed by the install manager are those in its install_dir.

   Setting the three directory settings to your alternate drive is an allowed way to achieve what you want. We don't have any support for using a runtime installed by a different user (which helps simplify our security model), but if two users have the same install_dir and can both access it, they'll share the runtimes. There's no technical need for them to be in the user directory, but it is a sensible default for us to choose because it means we don't have to also be responsible for ensuring users set things up securely - anyone who doesn't follow our default has to figure out security on their own.

   To directly answer the specific question:

   Can I keep a fully managed Python development toolchain under an explicitly controlled filesystem location, without moving more of its management state back into the Windows system/user-profile infrastructure?

   Yes, the install_dir directory is 100% of the management state and files for a full toolchain. The install manager is not part of the toolchain, we consider it a separate app, but if you also want to move that then you can, but you'll have to figure that out yourself. We explicitly don't support it, because it's a very easy way to break your machine and we can't be responsible for figuring out what you did so we can help you fix it. In the past, we have spent a lot of time trying to figure out these problems (caused by MSI configuration), and so we have chosen to omit the configuration and avoid the problems.

   Configuring a different install_dir is something we can probably help with, provided users give us all the details we need about the new configuration (many don't), but reconfiguring where the install manager lives is not something we want to worry about.

   I hope that makes sense, and you can see that we're trying to minimize the challenges faced by our volunteers when things don't work properly, rather than trying to go out of our way to "restrict" or "limit" advanced users such as yourself.

Issue actions