How to install "per machine" with several python runtime versions

[alexhass]

I find all these documenation about new install manager from 3.14, but I cannot find a single documenation about how to install system-wide together with several system-wide runtime versions. All points to no-go "per-user" installs.

I need to manage the software for all developers. Per user installs are an absolut no-go. This ends with uncontrolled and outdated software versions around and therefore security issues on all developer computers.

I need information for deployment (e.g. via Intune / PSADT):

1. How to install Python install manger "per machine"
2. How to install Pythons 3.14, 3.13, 3.12 in parallel
3. How to update every single runtime on its own as it may get released at different days.

Please share a link where this is explained step-by-step.

[zooba]

There is no support for per-machine installs in our install manager. If you want that, you should reach out to another distributor - we aren't the sole distributors of CPython, just the team who produces the source. You're more than welcome to get binaries from elsewhere.

Alternatively, you can use administrative configuration to point your users to a specific feed that limits what they can install, and then when they want to use a version it will pull from there. You can add py install -u as a scheduled task¹ to automatically update any installs (it will safely skip if they're in use).

You can install multiple versions with py install 3.12 3.13 3.14 (or any of the additional tags - use py list --online to see all the available versions from us. If you customise the default feed, it will show those instead).

Footnotes

1. You probably want the full path to pymanager.exe for this, but the conceptual command is py install -u. ↩

[alexhass]

It is not really helpful to point to other distributions. aside - I have no clue about others and what they are doing.

Implementing installers for "per user" only is a design flaw that need to be adressed asap. At least before you stop producing MSI setups for all versions, what seems to be planned for 3.15 from what I have read.

Alternatively, you can use administrative configuration to point your users to a specific feed that limits what they can install, and then when they want to use a version it will pull from there

No documenation about this, too.

You can add py install -u as a scheduled task1 to automatically update any installs (it will safely skip if they're in use).

What is also a very bad idea. I need to block execution and kill all processes and run a forced update. This can be done with PSADT, but not if there is just an MSIX and a bad per user install.

[zooba]

Implementing installers for "per user" only is a design flaw that need to be adressed asap.

Feel free to step up and make an installer that suits your needs. I'm sure you'll find some others who have the same need. You're under no obligation to make it freely available - there's a potential business opportunity here (intentionally), since we as volunteers have decided that it isn't worth our (free) time to maintain and support that class of install.

seems to be planned for 3.15 from what I have read.

After 3.15, so there won't be a traditional bundle of EXE and multiple MSIs for 3.16. There'll only be a ZIP package that gets downloaded and extracted.

No documenation about this, too.

You're right that it's not spelled out in a step-by-step, which makes it hard to put the pieces together if you're not already familiar with how the install manager works. I'm sure we'll get time to write something up once the existing functionality is reliable.

What is also a very bad idea. I need to block execution and kill all processes and run a forced update.

If that's what you need to do, then that's what you need to do, regardless of what installer is being used. If the processes are not in use, then you can update just fine. I think you're blaming a problem here on per-user installs when it's a universal problem?

I have my automatic update task scheduled for login, and my other login task that uses Python delayed by 30 seconds. It works just fine.

[alexhass]

I think there is a misunderstanding how software need to be installed on enterprise level. Admins need control about install and when and what. Users are simply never allowed to install random software. They cannot maintain security on their own. This is done by specialized teams that take care and protect the users from their inability to maintain a bunch of software packages. And enterprise need it to make sure no software is unpatched.

I’m also volunteering my free time here to help. But if maintainers ignore enterprise installs it is a very bad sign.

Again - installing software in local app data is always wrong. It is not only wrong today, it is wrong for last 25-30 years. If roaming profiles are around the folder is whipped on user log off from disk and the user need to install again every morning. With other words, the software is not compatible with windows. Have you expected that local app data gets wiped from disk if the user logs off?

Are you aware that per user software need to handle this behavior? That is why local app data should only hold temporary data that is allowed to get lost e.g. a temporary database copy of a primary database. Not software itself. This is a beginners fault… I hope you are not a beginner or so close minded and understand the 100 issues a user setup has in real life, not only me where I need to deploy to hundreds of systems what is simply not possible with msix crap.

[zooba]

It's not a misunderstanding, it's a deliberate decision to manage the amount of free labour we offer. We're not in the business of providing enterprise-ready software for free, we leave that to others to look after.

If you don't want your users to install random software, feel free to block the installer. If you still want them to use Python, then it's on you to provide it. We only offer a single install mechanism ourselves, but there are other options out there or you can build your own.

Depending on what other software you want Python to integrate with, you might just be able to use py install --download ... on your own machine and then set it up to extract into Program Files on your users machines. Possibly updating PATH as well (more reliable if you do it than relying on MSI), or adding enough registry keys to satisfy PEP 514. That's all we do (plus an uninstall entry, which you won't want, and Start menu shortcuts, which we don't recommend anyway).

My point is that it's not a huge job for you to do it yourself in your context, but it is a huge job for us to predict what your environment will look like well enough to build a tool for you and also everyone else who have slightly different environments. We carried bugs for years in the old installer that were unfixable without crippling regular users, and so they just stayed buggy. But the benefit that we get from doing all that work for the benefit of skilled administrators such as yourself is very small, so we're no longer committing our volunteers to do it.