Help with new Installation Direction

Python in Education
1

I need to caveat this with two things: I’m an Education IT support engineer, I’m not a programmer, or an educator.

I need to deliver updated Python into multiple suites. I need my suites to be locked down, so only admin users can (e.g.) access Powershell, or run unsanctioned EXEs.

The change to the Python Install Manager and MS Store based installations is concerning me.

As far as I can tell the current proposed scenario is:

Student A, sits at computer 1, they type “py install 3.14” and it downloads and installs to c:\users\StudentA\AppData\Local they do what they need to do and log off.

Student B sits at computer 2 the next lesson, they type “py install 3.14” and get their own Python install. So already, we’ve spent five/ten minutes of a 50 minute lesson teaching people how to install python. It’s not what they’re learning, but we’ve done it for A and B.

And C and D and E.

So, I , as an administrator can create a script which runs: “py install 3.14 –target C:\program files\Python” and then we’ve got a centrally accessible up to date python install.

However, they also want libraries: SciPy, NumPy, etc.

Whenever, in my testing, I run “py -m pip install SciPy” the Pip cheerily installs Python 3.14 into my admin account’s app data and then adds SciPy on top. So no-one else can access it.

How can I get my suites setup so they’re ready to go, no matter the user signing in?

Any help, much appreciated.

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

According to the PEP :

Administrator installs

Installing a copy of Python for all users is no longer possible, as PyManager will only install into the user’s own directory. No scenario has been presented to show that per-machine installs are in line with our intent for the upstream distribution, and so we will simply not provide an option for them. Third parties who desire this functionality are encouraged to provide their own distributions.

PyManager can only be installed for all users, though an MSIX does not require administrative privileges to install, and can be extensively configured by an administrator, including to constrain the actual runtimes which users may install. Additionally, PyManager supports local extraction for bundling, and so embedding apps can easily generate their own layout, which can be installed for all users if they so desire.

As this scenario requires administrator intervention with or without any changes, this will be documented only.

1 Like
3

Yeah, what Simon quoted is basically the case - providing integrated support for a lab-wide distribution like you describe is “too much effort” for our volunteer team, and so while there are some tools present that may help you, it’s not a feature of our distributions. Some other groups may provide a more suitable distribution for this (such as Anaconda).

You may be interested in the administrative configuration section of our install manager docs, which will let you put global settings in the registry that can limit/override how the install manager works. For example, you could set install_dir (from regular configuration) to your Program Files location, and then installs there will be found but non-admin users won’t be able to install anything.

You could include a pre-downloaded index on disk and set install.source to reference that, limiting the runtimes that users may install[1] and avoiding network access. And you could enable automatic_install and set default_tag[2] so that py <anything> will do the install if needed, saving the py install step.

And just to clarify from your post, installing with --target doesn’t register the runtime, so yes, running py -V:3.14 later won’t find it. It’s meant for things like bundling the runtime into your own distribution/app, not for choosing a different install location. There’s no more per-runtime install location, only one location for all installs, and if you change it (as mentioned above) then you’ll lose access to the old installs.

  1. Unless they override on the command line, which we will not block. py install --source <feed> <version> ↩︎

  2. And/or the currently undocumented default_install_tag setting, which is best cleared if you want it to match default_tag instead of being “3”. ↩︎

2 Likes
4

Thank you for the pointers. I do appreciate you taking the time to provide some direction.

I’ll take a look at the administrative configuration section and see what we can do from there.

I think we’re a different situation to “actual” developers, because we need homogenous environments everywhere for the students to work in.

If we didn’t have an issue of storage space, I’d love to suggest the students learn how to self install Python, add libraries, etc. etc. but these are the same young people who set a password they promptly forget the next week.

Thanks again for the support.

1 Like
5

Is there a reason to not prefer something like a JupyterHub system? Then students could have a link to a webpage on the desktop that opens up a Jupyter notebook. This is how many research centers solve the problem of shared resources with a common installation and thousands of users.

1 Like
6

I mean there’s lots of reasons. We have to vet everything with staff or student contact, get budgets approved, do due diligence. We’ll have to block the forums and any other community facility.

Largely the main thing preventing me is I haven’t heard of it before. I’ll put it under my Computing Department’s noses and see what they think.

Thank you.

7

You might check out https://2i2c.org/

2I2C is a nonprofit dedicated to helping education centers have access to computing resources. They might have some materials for running the full scipy / numpy stack.

As Steve mentioned too, Anaconda’s windows installer might have more features for fleet management and it is free in K-12 education environments.

1 Like