Suggest to add system-wide install for the new Python Install Manager (PIM) for Windows

Ideas
1

Hello Python Windows team and community,

I am writing to suggest an important feature enhancement for the new Python Install Manager (PIM) that would greatly improve its utility for system administrators, educators, and users in multi-user environments.

The Problem: Missing System-Wide Runtime Installation

The move towards the new PIM (MSIX package) is appreciated for enabling unprivileged, user-local installations and easy version management. However, this shift has complicated a critical administrative need: installing a specific Python runtime version (e.g., Python 3.14) for all users on a machine.

  1. Deprecated Method: The older, “Full Installer” (.exe) provided a clear “Install for all users” option, which satisfied this need by placing the installation in a centralized location like C:\Program Files.
  2. Current PIM Gap: While the PIM itself can be provisioned system-wide by an administrator (using tools like Add-AppxProvisionedPackage), the documentation notes that each individual user still needs to install their own copies of the Python runtime. This is problematic for:
    • Shared computing labs or classroom environments.
    • Centralized software deployment (e.g., SCCM, Intune).
    • CI/CD agents that need a guaranteed system-wide binary without being dependent on a specific user profile installation.

Proposed Feature: System-Wide Runtime Command

I suggest adding an administrative-level command or parameter to the py or pymanager tool to trigger a system-wide (all-users) installation of a Python runtime, requiring elevated privileges.

Suggested Syntax:

# Requires Administrator privileges
pymanager install <tag> --system-wide
# OR
py install -V:<tag> --all-users

Functionality Details:

  • The specified Python runtime (<tag>) would be installed to a non-user-specific path, likely within C:\Program Files.
  • The necessary system PATH entries and file associations for that version would be made globally available.
  • This command would only function when run by a user with administrator rights.

Benefits

  1. Simplified Deployment: Administrators can use a single, official Python-provided command to standardize Python versions across a fleet of computers.
  2. Consistency: Ensures that every user on the machine can access the exact same version of Python immediately, without needing to trigger a separate, individual installation.
  3. Modern Administration: Provides a command-line interface for system-wide installation, which aligns with modern DevOps and system management practices, filling the gap left by the deprecation of the Full Installer.

Thank you for considering this enhancement. I look forward to hearing the team’s and community’s feedback on the technical feasibility and desirability of this feature.

8 Likes
Suggest to add python debug / debugging symbols install for the new Python Install Manager (PIM) for Windows
2

I have multiple service accounts running Python scripts. Utilizing Python Install Manager will be a pain to implement across multiple servers.

3

The new Python Install Manager is great and the system-wide addition would make the Windows Administration complete.

As of now we have lots of system-wide installations via the old Python Launcher installer (which has its own install & uninstall problems) that need to be transitioned to a per user installation, which makes it more complicated.

4

This use case was mentioned recently in another thread:

5

There are ways to solve this. They are not as “automatic” as the old installer with its system install option, so they are likely to be unattractive to people who were happy with the old approach. But it’s important to remember that the old approach did have its own problems - just because some people didn’t have an issue didn’t mean that overall the system worked fine. So we (the Python core devs) took a decision to change the installer in a way that provided an overall improvement to the majority of users, at the cost of needing a bit more work from some users.

Unfortunately, the worst hit group is “informal sysadmins” - people like the poster you quote, who are effectively acting as a sysadmin for an environment, but who are not trained in that role. The solutions that work in a sysadmin context require skills that they don’t necessarily have, and quite possibly don’t have the time to work. That’s unfortunate, but not something we can do a lot about.

On a more positive note, the old MSI installer is going to be around for a while yet[1]. So there’s no immediate urgency.

Once you do transition over to the new manager, you have various options. You can use py install --target to download an installation to any directory you want. You can install whatever packages you want into that installation, and then put the path to it onto the global user PATH environment variable. You will have to manage that environment yourself, setting permissions appropriately so that users can’t (for example) use pip to add or remove packages, or instruct users on how to set up and use virtual environments so that they have an isolated environment to work with. You might need to remove the global aliases so that users can’t do their own py install command, if you’re concerned that they might “experiment” rather than stick with the documented processes. But all of that is possible - it’s just that you now need to think about what works for your situation, and support it yourself. That’s an extra burden, I completely agree. But it’s something you need to do once, and then your environment is set up.

Ideally, there could be documentation on how to set up such globally managed environments. The problem here is that none[2] of the core developers have any experience working in these sorts of situations, so we actually don’t know what good practices are here. So community-maintained documentation would in reality be far better than what we might provide. And the community that built up around such documentation would be a much better source of advice and help than general Python groups such as this one could ever be.

Of course, as with everything else, the people who need do deal with this situation don’t generally have the time to write documentation, form communities, or give advice to others. So getting a critical mass of interested contributors or participants is an uphill battle. But we can hope, can’t we? :slightly_smiling_face:

  1. In fact, at the moment the new manager is still in the “Pre-releases” section of the download page on python.org, so you need to explicitly choose to use the new manager ↩︎

  2. Or at least, not enough - and certainly not me! ↩︎

6

Hi Paul,

thanks for your input.

First of all I find it quite concerning that the “informal sysadmins” group is being so easily marked as a group that is simply not trained. I think that is understating the real struggles of managing python in Windows environment where versions need to be kept up-to-date regularly and may need to work with company security architecture such as application control mechanism

As to the technical points:

  • It is good that the old .msi installers are still around, but even they have some severe problems in the system context (un)installations (as you already pointed out)
    • I.e. Having 3.12 installed and installing 3.13 via the installer replaced the windows app entry of the previous version making it look like there would only be one version installed even though it is still on the file system
    • Uninstall via windows apps only removed fractions of the whole python installations
      • PATH Variables are not cleaned up
      • Files may still be present in Program files
    • And ofc with single installers every new version needs to be repackaged/reinstalled to keep the release up-to-date to avoid security vulnerabilities
  • All these Problems i.e. were points why I came across the new Python Install Manager
    • The PIM is a big improvement to the previous installer (i.e. because of the –update option)
    • However everything is user-based which may cause other problems in the windows world (i.e. when application-control solutions may be used)
      • thats why in secure windows environments you tend to avoid user installations to avoid the user installing any malicious software / packages or software not being up-to-date
      • it also makes the software deployment easier to be able to install it system-wide for all users
      • as known the PIM does not offer system-wide install
        • I tried your suggestion with “–target”, which allows the installation anywhere, however
          • PIM does not recognize it as installed afterwards (py list) → Auto-Up-Date not possible
          • No Windows Apps entry
          • Path needs to be added manually (as mentioned by you)

So as of now the only valid option is to use PIM with users installations and script these installations via software deployment software solutions as much as possible (i.e. I had to add all the path environments via powershell script manually)

I hope there will be a system context install for PIM some time in the future :slight_smile:

1 Like
7

Sorry. I should have said that my experience has been with people put in that sort of role without sufficient support or training. If that’s not the norm, then I’m extremely glad to hear it :slightly_smiling_face:

OK, but if that’s the case, I wonder why people are expecting the new manager to be any better? We did our best to make the old msi installer as effective as we could, and there’s no particular reason to assume the new installer would be different.

As far as I’m aware (and I’m not the person who wrote the PEP or the manager), the choice to focus on per-user installs was precisely because those were the cases we could make work the best. Windows Store applications are necessarily per-user (as I understand it) and integrating into that experience gives a good user experience.

Yes, that suggestion merely allows you to get a local copy of the Python runtime. Integrating it into your environment, and handling things like updates, is your responsibility. You can register the runtime using the normal registry entries, but that simply means the manager knows about the installation (so something like py -3.14 works), it doesn’t mean the manager will auto-update - manually registered installations are reported as “unmanaged” environments.

To be clear, we’ve never provided auto-updating Python installations, so the fact that we only provide them now for user installs is still an improvement for a large number of users. I’m sure that if we could have provided (and supported!!!) auto-updating system installs, we would have.

Maybe a 3rd party distribution like conda or ActiveState offers a managed, auto-updating system install? I’m not familiar with any of them, so I don’t know for certain, but if there’s demand, then as more commercial offerings, they may have (or be persuaded to develop) solutions.

I’ll leave others who have more understanding of the underlying OS technology to address your technical points further.

1 Like
8

True, I guess it’s somewhat physiological that new things tend to be seen as “better”.

Absolutely, I am not trying to say that its not an improvement :slight_smile: Having auto update for user installs is a game changer. I think user install are the main install for normal end-users.

My perspective is more from a company / enterprise side solely focused on windows with high security standards.

Looking forward to hear what other opinions there are on this topic