Feedback on beta of new Windows pymanager

[pf_moore (Paul Moore)]

@steve.dower

So it’s not a fair assumption that someone who modified their settings once can do it again, but what’s the alternative?

I wish I knew. I don’t know enough about the MSIX technology - every suggestion I’ve given so far about improving it seems to have been “we can’t do that”.

What I would like is that if you’ve got one of a set of known “unusual configurations”, the installer prints a message explaining the issue and advising you what to do. It appears that we don’t have any way to do that in the initial installer dialog, but I assume that we do control what the code that runs when the user selects “run after install”. That’s not ideal (I generally wouldn’t do “run after install”, because I don’t have a need for a Python prompt in a new window at that point) but if it’s the best we can do then fine.

Could we not at this point run pymanager check-settings or some similar subcommand, that did the job of trying to ensure that the user’s config was usable? That command would be potentially useful standalone, as well. For use in the installer, it could have an --initial-install option to run the existing behaviour after the check completes.

Actually, if it’s possible to omit the “Run after installing” checkbox and do that unconditionally, we could just auto-run pymanager check-settings --initial-install, and have the check finish with a “Pre-check complete - install Python 3.14 interpreter? [Y/n]” prompt.

@steve.dower

Short of building a GUI app that isn’t Python that gets launched when you launch Python (install manager)

Why does it have to be a GUI app? And how much of the “when you launch Python” is a limitation of MSIX, and how much is just not wanting to make the installation more complex? Because IMO, complexity to improve the user’s initial experience is a good investment. (That’s a genuine question, by the way - I really have no idea what MSIX can and can’t do).

@steve.dower

(volunteers welcome)

Unfortunately, it feels like you’re the only person in this discussion who really knows what the MSIX is and isn’t capable of. So I’m not sure what I could volunteer for.

Also, I don’t know how to programmatically query things like “is the python.exe app alias for the store enabled” so I can’t offer to write the checking code I suggest above. And now I have a horrible feeling you’re going to say that code doesn’t have access to that information. Which means I’d question whether we should even be using an app alias, rather than just having a python.exe in the same directory as the versioned executables. After all, that’s been sufficient for years… (Disclaimer: I personally use the launcher, so my view on what’s “sufficient” is uninformed).

@steve.dower

did you notice that message, which is already there

Yes, but realistically, very few people read the documentation until they hit a problem. That’s why I’m much more in favour of an approach that checks for known problems and then says “hey, this is going to be an issue, please check this link for instructions on what to do”.

[steve.dower]

@pf_moore

Unfortunately, it feels like you’re the only person in this discussion who really knows what the MSIX is and isn’t capable of.

Yeah, I’m far too aware of this If it’s any consolation, I’m apparently one of the more knowledgeable people at work, too - most devs avoid packaging and installers like the plague, or massively overestimate what the install tools are capable of (and I know you know this very well ).

@pf_moore

just having a python.exe in the same directory as the versioned executables. After all, that’s been sufficient for years…

It’s actually never been the case. We’ve had multiple directories added to PATH, each one containing a different executable all with the same name, and users had to manage that environment variable in order to choose the default by moving the entire directory up or down.

---

@pf_moore

It appears that we don’t have any way to do that in the initial installer dialog, but I assume that we do control what the code that runs when the user selects “run after install”. That’s not ideal (I generally wouldn’t do “run after install”, because I don’t have a need for a Python prompt in a new window at that point) but if it’s the best we can do then fine.

Yes, I think this is the best we can do, but we can probably do okay. Basically turn the first run into a console-based wizard and force users to enter…enter…enter… through it to get to the first Python install/launch. Launching from the start menu would also get you there, but hopefully if everything is clear then it’s silent. I filed Add interactive "first use" workflow · Issue #93 · python/pymanager · GitHub to continue this idea.

[pf_moore (Paul Moore)]

@steve.dower

It’s actually never been the case.

“Sufficient” = “Pretty terrible, but we’ve got away with it”

I don’t think it’s a good solution, but I also want to keep open the possibility that it’s better than fighting all the failure modes of the app alias approach. For now, let’s wait and see what other people’s experience is (I’ve been monopolising the conversation).

[jack1142 (Jakub Kuczys)]

@steve.dower

We can’t add a system environment variable though, because none of the installs are system wide. Only the current user gets their installs, and other users on the machine need to do their own installs. (And if Chocolatey is going to modify the system path then they’re going to break users who try to rely on that.)

That’s why I suggested to use %USERPROFILE%. The point is for each user to get their Python bin path in the PATH that the processes/shells they run see. Each user of the system can then not care about making modifications to the PATH because it will already include the entry for Python bin path. This should mean that they can run py install 3.13 and it will install 3.13 for that user and that user will be able to use python3.13 aliases (since bin path will then start to exist for that user). Requiring that each user of the system runs py magic-system-command is just an additional annoyance that can be avoided, when the system administrator sets it up correctly for all users through system PATH.

[steve.dower]

@pf_moore

“Sufficient” = “Pretty terrible, but we’ve got away with it”

We got away with it because people kept making YouTube videos about how to make it work And the people who ran into trouble figure out workarounds 10+ years ago and haven’t really complained about it recently. Changing anything was always going to reignite complaints, but they too will die down over time.

@pf_moore

better than fighting all the failure modes of the app alias approach

Bear in mind that the #1 advantage of app aliases is that they are already on PATH, so nothing has to be modified or even restarted.

[steve.dower]

@jack1142

The point is for each user to get their Python bin path in the PATH that the processes/shells they run see.

Right, but my point is that those other users don’t see py until they install it, and won’t have any installs until they do. So preemptively putting a non-existent directory there is just the kind of thing that someone will report as a security vulnerability and we either have to argue with them or concede and publish a CVE.

Any system administrator who’s managed to get PyManager installed for all their users is also entirely capable of setting PATH for all their users - likely more capable than we are, since their deployment tool probably has something built in for this, whereas we’d be registry hacking.

And in any case, I’m trying to position machine-wide installs as “possible but not encouraged by us” (someone else can do a distro if they want). So they aren’t prevented, but they should require a bit of hacking from an administrator who understands what they’re doing. We’ve got enough tricky scenarios to worry about with per-user installs, I don’t want to create even more.

[jack1142 (Jakub Kuczys)]

@steve.dower

Right, but my point is that those other users don’t see py until they install it

I guess I might have misunderstood the statement saying that PyManager / MSIX can only be installed for all users (but without requiring admin rights) from the PEP then. If that’s the case then I see your point

[steve.dower]

@jack1142

I guess I might have misunderstood the statement saying that PyManager / MSIX can only be installed for all users

Yeah, it’s a bit unusual. The application files themselves get installed by a trusted service, so they’re put in a single location for the entire machine and locked down to prevent modification, but only users that have chosen to install it for themselves (which is very quick if you’re not first) are able to launch it. I understand that it’s possible for an admin to “choose” that for all users, but it’s an “advanced, not directly supported by upstream” scenario.

I expect most admins will use the MSI though, since that saves them from having to understand newer tools. That basically behaves the same though - users still only install and use their own runtimes, and still have to modify their own PATH (which may be simplified by the step-by-step first run idea).

[steve.dower]

According to my dashboard, there have been almost 300 (unique) installs via the Store already, which surprises me as it hasn’t really been promoted that much. No way to tell how many installs from python.org, but since we still haven’t got it on the proper download pages (only the FTP page) I assume not many.

Anyway, today’s update (MSIX) has a highly requested feature, which is the interactive configuration steps. It should trigger on first launch (if you click “Launch” after installing or leave the checkbox selected), and currently checks for the following things:

• app execution aliases point to the newly installed package (and offers to open Settings if not)
• MAX_PATH still enabled (offers to fix it, requires admin)
• old py.exe isn’t on PATH (offers to open Installed apps if it’s there)
• new directory for versioned commands isn’t on PATH (offers to add it - screenshot below)
• any Python installs at all (offers to install default one if not)

And finally it shows the py command usage and offers to open the doc page. The defaults for all these are “no”, apart from installing the first runtime which is “yes” (same as before this change). Config options exist to disable each check (for admins), and the flow can be triggered anytime with py install --configure^[1]

---

1. In the spirit of the PEP process, I’m avoiding claiming any more top-level commands than what were originally proposed, which is why this one is a little bit awkward. Each top-level command is a script file that can’t be run just by name, and py configure seems one of the more likely candidates for a script with no extension. ↩︎

[jack1142 (Jakub Kuczys)]

Am I correct in thinking that Windows Server 2019 is still considered supported (PEP 11 mentions support until extended support, which suggests that is the case)?
I was unable to get the MSI install working (I imagine that is a solvable issue, I made one at Unable to access runtimes index on Windows Server 2019 · Issue #106 · python/pymanager · GitHub), and I also think that the normally preferred MSIX install won’t be easy to get working on Server 2019, see below.

---

Support for app execution aliases on Server 2019 is poor, so it might be worth noting in the documentation that MSI would work better there, otherwise, you run into problems, whereas there’s no way to actually use executables such as py.exe without (as far as I can tell) running complicated PowerShell commands to start it, only to be hit with missing DLLs when doing so.

Here’s a screenshot from 25.0b6 Start menu shortcut:

25.0b7 Start menu shortcut is “better” in that it doesn’t give you a scary popup, but it thinks that app execution aliases are not enabled, which may be confusing because the settings will tell you that they are enabled, even though they aren’t, exactly (you’ll get " ‘py’ is not recognized …" error in command prompt):

Switching it to off and then to on makes it so that the aliases are reachable by shell, but you’re still going to get “Access denied” / a popup telling you it doesn’t actually work:

If you use the magic incantation to open it in the context of the PythonManager package, you will hit the missing DLL popup that was seen on 25.0b6:

Anyway, my point is that the MSIX variant doesn’t seem easy to get working on Server 2019, and PEP 11 seems to indicate that this OS version is meant to still be supported so documentation update might be in order

[steve.dower]

@jack1142

Am I correct in thinking that Windows Server 2019 is still considered supported (PEP 11 mentions support until extended support, which suggests that is the case)?
I was unable to get the MSI install working (I imagine that is a solvable issue, I made one at Unable to access runtimes index on Windows Server 2019 · Issue #106 · python/pymanager · GitHub), and I also think that the normally preferred MSIX install won’t be easy to get working on Server 2019, see below.

Yeah, you’re quite likely right about all this. I’ll spin up a WS2019 machine later today and test it out - thanks for the heads up!

[notverygeordie (Peter Gosden)]

Hi there. Hope this is a sensible place to feed back! Had to get python onto an older Windows 11 installation. Decided to try PyManager - seemed to be timely! Installed using winget install pymanager, and then pymanager install default. All seemed good. Got banjaxed by the project I wanted needing wheel and pip not being able to install that because it’s not supported on Windows. So I used wsl ubuntu and that was all ok. (side note - I might have used python3 as the command line - you’ll see why that matters later).

A week or two later, running a build (batch) script on that machine, and it hung. Every time I hit ctrl-Cit’d throw up the help page https://docs.python.org/dev/using/windows.html# which was downright odd.

Eventually figured out what was happening. The script was simply trying to run python –version to figure out what was there. Except it was running c:\Program Files\pymanager\python.exe and throwing up the usage page and waiting for input - it asks if you’d like to go to the online help page - which in turn was what was being triggered by my ctrl-c!

And the reason why? The PATH entry for pymanager is in the System environment variables by default. The PATH entry for the installed version of Python is in the User environment variables by default. System is intentionally always ahead of User (specifically for PATH environment variables). So python on the command line always hits the pymanager version. Obviously python3 works fine - it’s not in PyManager. So the User-defined specific PATH entry points at the correct folder for the right version. Weirdly, py seemed not to misbehave in the same way. I assume because it’s going to call the correct python explicitly perhaps?

Thought I’d share. I found this thread whilst troubleshooting and while it didn’t help me clock the problem, it’s been good to read. Let me know if you have any questions. I’m pretty sure this would be 100% reproducible. I repeated it quite a lot trying to get my head around it.

If I’m right, it’d be a fairly common use case for folk to “install python using pymanager” and then “run script with calls to python” which would fail in the same way.

[steve.dower]

Thanks for the report. It sounds like a bug in the MSI’s python.exe in thinking that it’s the first run, rather than that it should be launching an install.

For what it’s worth, absolutely none of what you seem to have done here is the intended default path The MSIX and Store installers won’t put anything into the system PATH, and the MSI is intended for specialised users (e.g. enterprise admins). WSL is just Linux, and has nothing to do with the pre-built Windows distros.

We aren’t involved in whatever winget is doing here, so generally we’d say to reinstall with one of our supported methods and reproduce it. But in this case I believe you’re right and it should be easy to reproduce.

One piece of information you’ve omitted is the version that you’re using? It should be visible under Installed Apps (unless winget has hidden it, in which case we’ll need you to replace it with a supported install and try again). You can file bugs at https://github.com/python/pymanager rather than here if you prefer.

---

Edit: Confirmed that it’s just the MSI that is behaving badly (PR here). MSIX/Store appears to be fine.

[pitrou (Antoine Pitrou)]

@steve.dower

We aren’t involved in whatever winget is doing here, so generally we’d say to reinstall with one of our supported methods and reproduce it.

Hmm, should this part be stressed a bit more in Python Release Python install manager 25.0 beta 13 | Python.org ? It’s not clear by reading that page that winget is less supported than installing from the store ^[1].

winget is also recommended here:

To programmatically install the Python install manager, it is easiest to use WinGet, which is included with all supported versions of Windows:

---

1. It might be obvious for a Windows expert, of course ↩︎

[steve.dower]

@pitrou

Hmm, should this part be stressed a bit more in Python Release Python install manager 25.0 beta 13 | Python.org ?

The WinGet command we do support is shown there, which will get it from the Store.

I’m hesitant to list the command that we don’t support, as that feels a bit malicious towards the maintainers. I think I’ll update the GitHub templates to mention it, though. They don’t currently ask how it was installed, and it turns out that is pretty important most of the time.

[pitrou (Antoine Pitrou)]

@steve.dower

The WinGet command we do support is shown there, which will get it from the Store.

Ahah, sorry for misunderstanding, then.

[notverygeordie (Peter Gosden)]

Thanks for all of that!

When you mentioned using wsl being linux - absolutely: I just used the linux version of the stuff I needed.

PyManager version was the current latest in winget. Today, that’s 25.0.190.0, and I foolishly didn’t check specifics for you that day. Sorry! Having checked the PR and the tags in the repo against the metadata in winget I think I was probably on 25.0.189.0.

And yes, having followed the simple instructions rather than making it up off my own assumptions (“oh look - there it is in winget search Python I’ll use that then rather than the opaque store product id”), I hit the expected path… and, surprise surprise, python -–version installed the current version of python and printed out its version information.

[Kalanyr]

Since this is now the default with 3.14 builds on Windows, I’ve just had a crash course. Things have worked mostly okay for me with one problem: When I setup a pymanager.json with

{“default_tag”:“3.13”}

That makes py launch 3.13 ( which is fine) but py -3 launches 3.14 ( which is not, the reason I want to change the default is that I do not yet have necessary packages installed on 3.14 ). I’m not sure if there’s a secondary direction I’m supposed to include to tell it to redirect py -3 as well.

[steve.dower]

@Kalanyr

I’m not sure if there’s a secondary direction I’m supposed to include to tell it to redirect py -3 as well.

There isn’t. -V:3 (or the shorthand, -3) is and always has been an explicit “give me the latest installed 3.x”, and not “give me my default” (which you get by omitting it) or “check if my default matches PythonCore\3* and run that, and if it isn’t then do something that’s not at all well defined in this model”.

If it’s to do with packages, then once you’ve created a virtual environment with 3.13 and activated it, you don’t need to specify any version to py at all - it’ll just use your venv.

[Kalanyr]

Interesting.

I was going of this: https://github.com/python/cpython/issues/105548

Which suggests it was possible to redirect py -2 and py -3 and such before with the previous py albeit by specifying a specific default rather than an opt in flat.