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

[a-vago]

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.

[zooba]

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.