Cannot uninstall Python 3.14b0

[pfmoore]

Describe the bug
See https://discuss.python.org/t/python-3-14-0-beta-1-is-here/91117/20 for the background.

I have Python 3.14b0 installed via pymanager. But pymanager uninstall 3.14 fails to uninstall it, despite saying it has done so.

To Reproduce
Steps to reproduce the behavior:

It's difficult to describe how I got where I am concisely. All of the details are in the Discourse thread linked above. Basically I installed pymanager, which installed Python 3.14b0. I installed 3.13 and 3.12 using pymanager, then I uninstalled the old MSI-based installations and cleaned out the old registry entries. I also uninstalled the old py launcher.

With that background

1. In a Powershell prompt.
2. Run pymanager uninstall 3.14. Say "yes" to the prompt.
3. The message "Removed Python 3.14.0b1" is displayed.
4. Run py list. Python 3.14 is still there. Running python confirms this, as the Python 3.14b0 REPL starts up.

Expected behavior
The requested uninstall happens, leaving Python 3.13 as my default Python.

Additional context

python_uninstall_20250509213807_19892.log

[zooba]

I know you've done a lot with your system since this, but I don't suppose you can get debug output from a py list -vv command? The uninstall log looks clean, and it doesn't immediately detect any 3.14 installs (luckily there's a log message to that effect, as it's looking for the default install), but potentially a list command log will show why it's finding one. (py list only saves its log file if it crashes, so passing -vv and capturing the output is easier than trying to catch the file.)

[zooba]

My initial guess is that there's still a bit of registry corruption going on, but I don't think you ever installed 3.14.0b1 from anywhere other than PyManager, did you? So it must have failed the uninstall badly if it confirmed that the files were deleted but they were still there. I'm not sure how that could happen - I spent a lot of time on file deletion (too much...)

[pfmoore]

I know you've done a lot with your system since this, but I don't suppose you can get debug output from a py list -vv command?

Unfortunately, no. I uninstalled everything, cleared the registry, and reinstalled Python 3.13 from the MSI, as it was the only reliable way I could get back to having py default to Python 3.13. And I needed a working 3.13 for scripts I run daily.

My initial guess is that there's still a bit of registry corruption going on, but I don't think you ever installed 3.14.0b1 from anywhere other than PyManager, did you?

Correct on the point about never installing 3.14b0 from anywhere else.

I don't know if you saw on Discourse, but moving the 3.14 directory out of $env:LOCALAPPDATA\Python stopped it appearing, at which stage I deleted it. But the python command reinstalled it, and I'm not clear if that's intended behaviour.

I'll do some more testing, if the intended behaviour is that if I install pymanager, and either don't install 3.14b0 as part of the install, or uninstall it straight afterwards, then the python command and the py command will default to running my existing Python 3.13 installation (installed from MSI). But if 3.14b0 is forced on me, I'm afraid I won't. I don't plan on doing testing of 3.14¹ so unless I can test the manager without getting 3.14 introduced into my environment, it's not something I can really afford to do.

I did reinstall pymanager (25.0b5). One small thing, it says "Install Python" even if you uncheck "Run after install". That's misleading, and concerning, as I explicitly unchecked that box so that it wouldn't install Python, just the manager. I'd rather the button said "Install Python Manager" and the checkbox said "Run (and install Python) after install".

It does now cleanly install and uninstall Python 3.14 without issues. But pymanager exec (the shortest incantation that works without messing further with my system) still installs 3.14 rather than starting 3.13. And unless I've missed something, there's no way (short of fiddling with config files, which puts me right back into having a "weird setup" territory) to change that default. So that's as much as I can do for now.

Footnotes

1. Not enough time, and most of my usage is pretty basic or relies on 3rd-party modules. ↩

[zooba]

I don't know if you saw on Discourse, but moving the 3.14 directory out of $env:LOCALAPPDATA\Python stopped it appearing, at which stage I deleted it. But the python command reinstalled it, and I'm not clear if that's intended behaviour.

Yeah, this is intended. It's really quite a simple registration process - we look for <rootdir>\*\__install__.json and only those that are found are "registered". So deleting the directory cleans it up without having to touch any other stored files. But this is why the uninstall command starts by deleting the JSON file, and the logs claims that it did that, so I'm confused as to why it was still showing up.

One small thing, it says "Install Python" even if you uncheck "Run after install". That's misleading, and concerning, as I explicitly unchecked that box so that it wouldn't install Python, just the manager.

I don't think the button should go that big, but it's easy enough to remove the customisation to add "Python" to the button. Going back to "Install" is fine by me. I don't think it's that misleading though, and you may be reading too much into it - clicking that button does indeed install the python command, which means "python" to most people. I might wait for a second vote of "misleading and concerning" before changing anything there.

[zooba]

I'll do some more testing, if the intended behaviour is that if I install pymanager, and either don't install 3.14b0 as part of the install, or uninstall it straight afterwards, then the python command and the py command will default to running my existing Python 3.13 installation (installed from MSI). But if 3.14b0 is forced on me, I'm afraid I won't.

This is quite the ransom demand, and I'm not sure if I'm being overly sensitive or if you're being frustrated.

Set %PYTHON_MANAGER_DEFAULT% to 3 in your OS or create %AppData%\Python\pymanager.json¹ and add {"default_tag": "3"} and it'll behave like that. That'll eventually be the default, but I wasn't planning on switching it until "3" implies "3.14" (because we've released the final - follow #8 for that one).

Footnotes

1. Note that that's %UserProfile%\AppData\Roaming\Python\pymanager.json, not "AppData\Local". ↩

[pfmoore]

This is quite the ransom demand

Oh heck, sorry - I didn't intend it like that at all. All I was trying to say is that I only have my one main PC, and I can't afford to use the Python 3.14 beta as my main Python on that PC. I'm more than happy to test the new manager (indeed, I really want to do so) but if doing so is tied to using 3.14, I'm not going to be able to find a test environment where I can exercise the manager in "real world" situations.

I hadn't gone looking for the config to change the default (I was aware that there might well be one) because you'd taken a pretty hard line on "if people make config changes, they need to be prepared to deal with the consequences" over other things like the app aliases, and I didn't want to end up simply making both our lives more frustrating if I kept encountering issues you classed as "user config problems".

So in the interests of not misunderstanding, if I add the default tag to pymanager.json, that's a fully supported configuration, and I can keep my existing MSI installed copy of 3.13, and I'll never see any sign of 3.14b0 unless I explicitly request it? Essentially, exactly the same as I'll get with the final pymanager released with 3.14, when the 3.15 release cycle starts? Oh, and one other point - to end up with a clean "as intended" install after 3.14 is released, I assume I'd need to uninstall the manager, make sure pymanager.json was removed (so I was getting a "pristine" config) and then reinstall?

#90 (combined with #91) is still a bit of a blocker for me, but I'll see if I can work around that.

[zooba]

So in the interests of not misunderstanding, if I add the default tag to pymanager.json, that's a fully supported configuration, and I can keep my existing MSI installed copy of 3.13, and I'll never see any sign of 3.14b0 unless I explicitly request it? Essentially, exactly the same as I'll get with the final pymanager released with 3.14, when the 3.15 release cycle starts?

I'll say a weak "yes", or perhaps better phrased as "I sure hope so, please file a bug if not"! The Standard configuration options are intended as user controls, and are fully supported. There's a later table of "things you might configure if you're deploying this for your enterprise" type items, which are also fully supported, but are far more likely to get you into trouble if you mess them up (and most users won't ever need or want them).

Simply removing the config file later is sufficient, there shouldn't be any need to reinstall anything. But the "pristine" default setting will be "3", so you're just getting there early.

[pfmoore]

perhaps better phrased as "I sure hope so, please file a bug if not"!

That's good enough for me! It means I'm not testing exactly the default setup, but I am testing a supported setup, which is all that matters to me.

Simply removing the config file later is sufficient, there shouldn't be any need to reinstall anything.

OK, thanks.

[zooba]

I hadn't gone looking for the config to change the default (I was aware that there might well be one) because you'd taken a pretty hard line on "if people make config changes, they need to be prepared to deal with the consequences"

I'll also clarify that the hard line is between settings controlled by us vs. settings controlled by the system. So essentially, if it's one of our configuration files or environment variables, then we are responsible for the consequences. If it's a setting owned and handled by the OS (such as PATH, app execution aliases, or other installed apps/MSIs) then my rule of "past manual modification implies that you're capable of future manual modification" applies (and its corollary, that lack of modification implies you shouldn't need to make any unprompted modifications).

[zooba]

I don't see how to progress on this issue as it stands, so let's hope it was either a one-off or it's been resolved by other changes.