Feedback on beta of new Windows pymanager

Core Development
1

OK, so I gave it a try (finally). The following is a summary of what the experience felt like. I hope that’s useful - I don’t think it really justifies creating a bunch of small issues (although I’ll happily do so if there are particular points that warrant it).

My PC has all of Python 3.8 - 3.13 installed from the official Python installers. I don’t have the Windows Store Python installed, but I did disable the python.exe and python3.exe app aliases, so they wouldn’t start up Windows Store. Not a typical situation, but not incredibly far from vanilla.

I installed the manager from the python.org link. It installed successfully, and then installed Python 3.14b1. So far, so good. Of course, now the old py launcher defaults to 3.14b0, which sucks, but is a known problem with the old launcher.

The python and python3 commands still don’t work. I assume that’s because I manually disabled them, but it’s still annoying. Turning them off because the store is not what you want them to do seems like a rather normal thing to do. But I guess that’s something we have no control over :slightly_frowning_face: Anyway, I re-enabled them. But that’s no use, they still start the Store. Surely that’s not the intended behaviour? I’d have wanted them to now run the newly installed Python via the manager, as that was the advertised behaviour.

Ah, I see. There’s two app aliases for python - “Python (default)” and “App Installer”. Again, not easy to understand, but I guess not something we can fix. Maybe some docs around this (and some help text on first install) would be useful?

Now Python runs 3.14b1. I did pymanager install 3.13 and it says it’s installed but “A runtime matching PythonCore\3.13 is already installed, and so the new one has not been registered”. Fair enough, I didn’t want to remove the old 3.13 just yet, as I have a pipx setup to sort out first. But it also says that the python alias will now run 3.13, and that’s not true. It still runs 3.14b1. Do I have to uninstall the old MSI-based 3.13 to use the new one?

My concern here is that I have a bunch of stuff set up with pipx, and I’ll need the old Python to run them, at least until I recreate the venvs. But I can’t run pipx under the new 3.13, because it’s not accessible until I remove the old 3.13. After some more exploring, it seems that pymanager exec -3.13 works to start the new 3.13.

So pymanager exec -3.13 .../pipx.pyz reinstall-all seems to have done what I needed it to.

I tried uninstalling 3.12. It uninstalled fine, but pymanager install 3.12 said “An existing registry key for PythonCore\3.12 was renamed to 3.12.0 because it appeared to be invalid”. It also mentioned that same message about 3.13 again (why? I’m trying to install 3.12). And python still runs 3.14b0, not 3.12. In this case the message didn’t claim python would run 3.12, so I guess that’s fair (although when it said it would run 3.13, that was a lie, so I’m suspicious at this point).

So I guess I now have questions.

  1. How do I fix 3.12, as I seem to still have stuff from the old 3.12 installation present?
  2. Can I safely uninstall 3.13? I fear it’ll do the same as 3.12 did.
  3. Can I fix the new 3.13 to work via python without having to delete the old one?
  4. How do I set the default Python to not be 3.14b0? I thought the new manager was going to prefer final releases over betas.
  5. More generally, can I change the default for the python command? I don’t really care as long as it defaults to the latest final release, but it seems like something people might want to do.

I think I might have to uninstall everything and tidy up for now. I don’t want a system where the new beta version is my default Python - that’s going to mess too many things up :frowning:

As I said, I hope this helps. If there are specific items that are worth raising on the tracker, I’ll happily do so. Also, I’m more interested in what the “official” advice to help users in this position should be - I’m in a privileged position, as I can beg @steve.dower directly for help, and in any case, I’m perfectly capable of hacking my registry, uninstalling and cleaning up, and getting things working. I can personally sort things out without hand-holding. My aim here is more to describe a scenario that could come up for someone not in my position, so we can improve the initial experience.

3 Likes
2

Yeah, and my requests (~5 years ago) to improve the UI here were rejected. I’m still bugging people about it, so with a bit of luck it’ll get a facelift in the future.

FWIW, if you’d left the original aliases active, installing PyManager would have taken them over. That’s atypical behaviour here, but I insisted on it and so it was added to the OS (the Store redirector has a special flag on its aliases to let them be “stolen” - but once you’ve said "I don’t want global python.exe, then the OS remembers that!)

This is worth filing as a bug.

This probably needs to be a more detailed warning about exactly what hasn’t been registered (it refers only to PEP 514, and not to py ... invocations[1]). File a bug?

:tada: This makes me glad. (Though I’d prefer to see py -3.13 ..., so we don’t lead people to think the idea is they have to type 5x as much.)

The only way to ensure the shortcuts are consistent is to refresh all of them each time. It matters less for the registry, but if you installed 3.12 first and it generated python3.exe, then installed 3.13, it has to recalculate all of them.

Hiding warnings unless they’ve been specifically requested is possible, but I’d call it feature work. It might require a lot of coupling between currently decoupled parts of the codebase. Worth filing a bug.

The warning should have said you can delete the old key? If not, well, you can delete the old key. Not cleaning up the registry properly is another bug with the old installer that there’s no good way to resolve now. (FWIW, “appeared to be invalid” means that it doesn’t point to an install anymore, but still has some values in it, and we can’t assume it’s safe to just silently delete.)

It should be fine. If you run py install --refresh after uninstalling then it’ll redo all the registry/etc. and make sure it’s up to date.

It should do. I assume you mean through py -V:3.13 rather than by default (see next point for “by default”). Can you capture py -V:3.13 with $env:PYMANAGER_DEBUG=1 and file a bug?

It will, but the challenge right now is that I want it to include 3.14 by default, rather than 3.13. That means the default is temporarily “3.14” rather than “3”. You can override the default tag using configuration in the meantime.

Yes, greatly! Many thanks.

If you don’t get to them, I’ll put them up. But more than happy to have you post directly (especially for the ones where I’d need to see logs to guess what’s going on).

Did you find your way to the docs during this scenario? I don’t really know how much we can just pack into the UI (which as you’ve noted, is already a bit noisy when it comes to warning about things that aren’t quite right). There should be a few pointers to https://docs.python.org/dev/using/windows.html, but honestly if someone doesn’t go through to it and have a read, they’re probably going to need hand-holding a times.

  1. Which are practically synonymous with pymanager exec .... ↩︎

1 Like
3

Bunch-o-existing Pythons: my case too, supporting a project that is promised (at the moment) to work on 3.7->current, and I add the 3.14 pre-release. And disable the unwanted app aliases, as they blow up the test suite (*see note), popping up the store prompt instead of using the Python actually in use. So at least two of those setups exist :slight_smile:

Does the new setup still respect the py.ini file? @pf_moore that would be the way to force the default, if a bit awkward…

(the test suite problem is our bug, a lot of care is taken to use sys,executable in launching external things, but there are still some places ‘python’ leaks through, proven hard to stamp out)

4

And for what it’s worth, I invite everyone to beg me for help while we’re in beta. I want to hear about every experience, good and bad, so that we can make changes and updates based on actual experience and not just my own guesses.

7 Likes
5

Oh, that’s good. If I uninstalled everything, went back to how I was at the start, and then enabled the Store redirector aliases, and then installed pymanager, would that take over the aliases, or have I misunderstood?

Will do. I’m not sure if I can create a reproducer for it, but I can certainly describe what I did.

I can if you want, but it was perfectly clear to me that it was referring to PEP 514 registry data. And I completely understand that you can’t have 2 registrations for the same version. I only mentioned it in case it was relevant to the behaviour of python (there’s only one pymanager-managed version of Python with PEP 514 registration data - it’s a bit of a stretch, but maybe that’s why it’s still picking 3.14b0).

I couldn’t use py because I have the old launcher installed. I want to remove that last, because it’s the hardest to restore as it doesn’t have a standalone installer.

I should also mention that python3.13 doesn’t work - it’s probably obvious from the fact that the app aliases didn’t pick up 3.13, but maybe not…?

Will do. But I agree it’s a minor point (certainly once you know what’s happening, and I’d assume most people wouldn’t have the problem in the first place).

It did. I would have done it anyway, as I have no particular fear of the registry. But ideally, “hack the registry” shouldn’t be a routine user-level fix. Having said that, garbage in the registry is an endemic issue and Python installations aren’t immune. So nothing new to see here.

:+1:

No, I meant via python (but your point below covers that). As an interim question, is it not possible to have the old 3.13 still installed, plus the new one, and have the python3.13 app alias run the new 3.13? I’m going to assume not, and I think that’s OK.

If I rename the old py launcher out of the way, py -V:3.13 launches the new Python 3.13 as expected. So this is actually fine. (There’s no way to launch the old 3.13 in that case except by using the full path to python.exe, but I don’t see that as an important scenario to cover).

Ah, I wondered if it was deliberate to prefer the beta for the moment. I think I disagree with that choice, as it makes it unnecessarily hard to test the new manager without also ending up testing the new Python version (although I guess just uninstalling 3.14b0 is a fix for that). But it’s a fair choice, and I’m not going to fight against it.

I think I have three to do:

  1. Saying that python will run 3.13 rather than 3.14b0, which is what it actually runs.
  2. Hiding warnings about versions other than the one you’re installing.
  3. Explaining that “registered” refers to PEP 514 (although I’m not convinced anything is needed here).

I’ll be honest, I didn’t try. I knew there were docs, but for better or worse I did what I’d normally do and dove straight in expecting everything to be “intuitive”. The pymanager help does link to the docs, though, so I did see that there was information there. (And if it makes you feel better, I did feel a little bit guilty ignoring it :slightly_smiling_face:)

I just took a brief look, and it’s pretty much as I expected - the significant point about my setup is that I have existing Python installs, and I want to replace them with pymanager-managed versions. That’s never going to be a “basic usage” situation, and IMO it’s fine not to focus on that in the main docs. I did hope that it would be a section in “Advanced Installation”, and I’m sad that it isn’t. Even something as simple as “uninstall any existing interpreters that you want to replace with pymanager-managed versions, manually check that the registry entries are gone, and uninstall the py launcher” would be useful. With that, the only concern I would still have had would be “how do I hunt down (and fix) places that point to my old installation?” That includes:

  • Virtual environments - delete and recreate them, ideally. Bonus points for covering how to deal with ones that have a bunch of things installed and no maintained requirements file (pip freeze, recreate, pip install).
  • Pipx managed applications. I still don’t know if I need the old interpreter installed when rebuilding, but assuming I don’t, pipx reinstall-all will work, if pipx picks up the new managed interpreter.
  • File types. I don’t know what will happen here, but at the moment, I have python.file="C:\WINDOWS\py.exe" "%L" %* which will break when I remove the old py launcher. And I don’t know what to replace it with (it looks like the manager didn’t set anything up).

(There’s also a bunch of custom stuff I’ll have to find and fix. That’s on me, though).

At this point, I might just try a full uninstall and start from scratch approach. Uninstall pymanager and the managed executables that I have, then uninstall all my existing Python interpreters (and manually wipe the registry). Then start clean with pymanager only. It will be interesting to see if that’s a smoother experience.

2 Likes
6

I think we have a py -m venv <some option> option that will update it in place? I personally just edit the pyvenv.cfg to point at the new install :upside_down_face: venv’s are pretty robust once you ignore their Scripts directory (apart from activate).

It should’ve, you should see “Python (default)” listed under Open With, and if you choose to “Always” use that then it’ll take over the file association (and add the Edit With IDLE menu). It should behave almost identically[1] to the existing one, though it may not show up in the usual registry entries and so older tools may not show it.

I’d imagine so, and eventually this will be the only experience. The transition period is the tough part, but your feedback is helpful.

A “Migration Guide” is probably a good way to draw attention to the install manager, and is something that can be retired sooner than regular documentation. I’ll make a note to do something along those lines (once enough early-early adopters have provided feedback so we know what needs to go in it).

  1. I discovered one gap today in that we can’t enable dropping files onto a .py file and having it launch the script with the files as arguments. Probably nobody has ever noticed that you can do that with the old launcher, but the OS feature registration isn’t available to MSIX right now… ↩︎

1 Like
7

Oh yeah, we do. I never use it either, but that would work.

Ah, yes it does that. I was surprised because the old installer actually added the association, rather than just providing it as an option.

I have to say that it’s annoying that you have to do that for each file extension separately. Especially as I want it for CLI usage - I have PATHEXT containing .py and .pyz and so I need to “run” a .py file and a .pyz file, which will pop up the dialog and run the command in a separate console window. Once that’s done, it’s sorted and from then on running a .py will run it in the current shell as expected.

I was a little surprised that ftype python.file still shows python.file="C:\WINDOWS\py.exe" "%L" %*, given that I no longer have a C:\Windows\py.exe. I guess that’s what this refers to. I feel that some advice on how to tidy this up (maybe even a script to do it) would be useful here.

And regarding the footnote, I knew about that and may even have used it occasionally in the past. I’m not going to be devastated that it’s gone, though.

Yes, I’d be strongly in favour of that. Even though, as you might suspect, I’d probably still just dive in blind myself and then look vaguely embarrassed when someone asked me if I’d read it :slightly_smiling_face:

I’ve changed my mind. I think it would be an easier experience for me, but I don’t think it would generate many useful insights. I’ll continue on my “hack it until it works” journey, and report on my adventures. Once I’ve got what I can from that, I’ll only then do a full uninstall and install from scratch.

2 Likes
8

The ftype situation is pretty complicated now. I won’t try to explain what @eryksun wrote about that when I was running into problems, as I still lack the expertise, but hopefully it’s correct to say what ftype tells you is only part of the story, no longer the whole story.

1 Like
9

So I’ve now:

  1. Uninstalled Python 3.13 (the old MSI installer version).
  2. Uninstalled and reinstalled 3.13 via pymanager.
  3. Deleted the old registry entries for 3.13 and 3.12.
  4. Uninstalled the py launcher.

I now have

❯ py list
Tag               Name                  Managed By  Version   Alias
3.13[-64]         Python 3.13.2         PythonCore  3.13.2    python[w]3-64.exe, python[w]3.13-64.exe, python...
3.12[-64]         Python 3.12.10        PythonCore  3.12.10   python[w]3.12-64.exe, python[w]3.12.exe
3.14-dev[-64]  *  Python 3.14.0b1       PythonCore  3.14.0b1  python[w]3.14-64.exe, python[w]3.14.exe

* These runtimes were found, but cannot be updated or uninstalled. *
3.11              Python 3.11 (64-bit)  PythonCore  3.11.6
3.10              Python 3.10 (64-bit)  PythonCore  3.10.11
3.9               Python 3.9 (64-bit)   PythonCore  3.9.13
3.8               Python 3.8 (64-bit)   PythonCore  3.8.10

Some columns were truncated. Use '--format=json' or '--format=jsonl' for full information.

Note that python[w]3-64.exe and python[w]3.13-64.exe claim to be aliases for Python 3.13. But they don’t work:

❯ python3-64.exe
python3-64.exe: The term 'python3-64.exe' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

There are no entries in the “App Aliases” applet for these. I don’t think there should be, but I don’t know any other way of debugging this. I checked where python.exe is stored ($env:LOCALAPPDATA\Microsoft\WindowsApps) and we have

❯ dir $env:LOCALAPPDATA\Microsoft\WindowsApps\py*

    Directory: C:\Users\Gustav\AppData\Local\Microsoft\WindowsApps

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          09/05/2025    15:24                PythonSoftwareFoundation.PythonManager_3847v3x7pw1km
la---          09/05/2025    15:24              0 py.exe ->
la---          09/05/2025    15:24              0 pymanager.exe ->
la---          09/05/2025    21:23              0 python.exe ->
la---          09/05/2025    15:32              0 python3.exe ->
la---          09/05/2025    15:24              0 pythonw.exe ->
la---          09/05/2025    15:24              0 pyw.exe ->
la---          09/05/2025    15:24              0 pywmanager.exe ->

OK, weirder and weirder. I uninstalled 3.14 - pymanager uninstall 3.14. Running python still starts it! And py list still shows it. Same when I did pymanager uninstall 3.14-dev.

This is rather bad. I now have a Python 3.14b0, that’s insisting on being my default Python, which I cannot uninstall. The only thing I can think of doing now is pymanager uninstall --purge, and see if that cleans up. I won’t do that yet, in case there’s useful data I can collect on what’s happening with 3.14, but I’ll have to do so at some point soon.

I’ll raise a bug, as it may be better discussed on the tracker.

1 Like
10

Did you try:

  • Exiting the shell/Terminal and starting a new one?
  • Rebooting?

I am dead serious.

11

Yes to the first, no to the second. I did log out and back in again, though, which is usually sufficient. I’ll check again in the morning, as I’m shutting my PC down shortly anyway.

12

One thing to check is that %LOCALAPPDATA%\Python\bin is on your PATH – the alias executables are all located in that folder (at least for me). From memory, if it is not on your PATH, PyManager will prompt you about it, but only when performing an install command.

A

1 Like
13

From my POV, that switch really should be interpreted as “I don’t want my CLI to spawn the windows store”, rather than “I don’t want global python.exe”. I very much do want the latter[1], but am willing to do literally anything to avoid the former.

  1. though not from the store, obviously ↩︎

3 Likes
14

Ah. That’s the message

Global shortcuts directory is not on PATH. Add it for easy access to global Python commands.
Directory to add: C:\Users\Gustav\AppData\Local\Python\bin

My eyes skipped over it every single time I did an install. I don’t know why, although maybe the friendly blue colour isn’t as attention-grabbing as red would be…? My mistake, and thanks for pointing it out!

Is this another one of those “we can’t do anything about it” problems? Because honestly, the accumulation of them is a lot more annoying than I expected. Yes, I can add that directory to my PATH, but then I’m responsible for managing it (and for removing it if I uninstall pymanager).

I’m starting to feel like we might need to look for better options here.

1 Like
15

After a reboot, I still can’t uninstall 3.14 :slightly_frowning_face:

py uninstall --by-id didn’t work either.

OK. So I renamed the pythoncore-3.14-64 directory to xx, and weirdly it was still recognised as Python 3.14. And python ran it. I then moved it out of $env:LOCALAPPDATA\Python. At that stage, it finally disappeared from the list.

But the python command reinstalls it!!! Surely, if I have Python 3.13 installed with pymanager, python will default to that, and not install the new beta? Even if we want to encourage people to test the new beta, that’s going too far IMO. The py command does the same, which is even worse, as that’s not even compatible with the old py command.

Good news, though, I can now uninstall 3.14 cleanly. (The python command still reinstalls it, of course :slightly_frowning_face:)

OK. This is as far as I can go, I think. With the "always install 3.14b0` behaviour, the new manager is unusable for me on my main PC, so I’m going to have to uninstall everything and reinstall the old MSI installers for 3.13 and 3.12.

@steve.dower - I hope this is enough information for you, and it’s of some use. I’ll try the manager again once 3.14 is released, or maybe when the “force you to use the beta” issues are sorted out.

16

(Occurs to me that this should be spun off as a subtopic referencing the new pymanager – not sure how to do that!)

@pf_moore – would you be able to post here the refs to the bugs you’ve raised already, please? I’m trying to see whether what I’m experiencing matches issues you’ve already raised, or are different…

The main issue I’ve hard so far – and I haven’t tried anything complex – is that the pythonx.y aliases don’t work as promised. Not for the default 3.14b1 install; nor for a subsequent 3.13 install I did fresh.

3 Likes
17

Agreed about making this a separate thread - @admins can someone split this at this message?

Issues are

Most of the rest of the things I’ve hit I’d classify more as “user environment issues”. They may well hit other people, but it’s hard to know how to report them as bugs if the position is “we can’t deal with every possible user environment quirk automatically”. I’m happy to create more issues if @steve.dower confirms that it’s worth doing so, though.

1 Like
18

That’s probably because you need to add $env:LOCALAPPDATA\Python\bin to your path. The installation output mentions it, but it’s (IMO) easy to miss (i.e. I missed it too :slightly_smiling_face:). I’d personally prefer it if the manager added that directory automatically, but I’m not sure I have the energy to fight Steve over the whole “we can’t modify the user’s path” question again…

19

That’s probably because you need to add $env:LOCALAPPDATA\Python\bin to your path

No; I’d done that. (Helped by the fact that you highlighted it when you realised you hadn’t!)

20

Thanks. So I’ll double-check the PATH thing before raising a specific bug against the pythonx.y executable

UPDATE: sorry; your issue#83 is the same bug as I’m talking about.

UPDATEd UPDATE: and a restart of the command shell (combined with already having added to PATH) fixed the pythonx.y problem