Python Manager MSIX does not install. Secureden?

[Poddster]

Install source and version

• Installed from the Windows Store
• Installed with the MSIX from python.org
• Installed with the MSI from python.org
• Installed with winget install 9NQ7512CXL7T

Version: 26.1.240.0

Describe the bug
It doesn't install. I click install, it gets to 98%, I then get this error:

App installation failed with error message: AppxManifest.xml(150,26): error 0x80070020: Cannot register the PythonSoftwareFoundation.PythonManager_26.1.240.0_x64__3847v3x7pw1km package because the following error was encountered while registering the windows.appExecutionAlias extension: The process cannot access the file because it is being used by another process.
. Try again and contact the package publisher if the problem persists. (0x80070020)

To Reproduce
Steps to reproduce the behavior:

1. Click install

Expected behavior
I expect it to install.

Additional context
I can't see any specific logfiles in %TEMP% that go with python manager

I work in a "secure" IT environment (using secureden), and each instance of admin elevation has to be approved by IT.
However the installer/UAC is not asking me to elevate to admin, so I'm not sure if that's the issue. I can't see a way in file explorer to run the .msix as admin, as the "right click > run as admin" option is only for .exe, and I don't fancy asking IT for a admin command prompt :)

The "windows store" is disabled by IT policy.

[zooba]

Are you able to install WinDbg using the "Download WinDbg" link at that page? They're using much the same system as we are, including creating app execution aliases (though theirs don't exist initially, so it may succeed).

It's possible that if you open Manage app execution aliases and disable all the existing python.exe-like options, it might help work around this particular problem. But I'm only guessing, since your problem is not caused by us.

I suspect in this case you're going to need to go through your IT department and possibly report it to secureden.¹ You don't need admin to install using the MSIX and it won't help. Most likely your IT department has just locked things down too hard and broken stuff.

They may prefer to deploy the Python installer MSIX themselves, or maybe the MSI. It's intended for that - it would only give all their users a py command, and doesn't install Python itself unless they use it. There's a whole section in the docs on admin configuration that they could also roll out if they need additional controls.

Ultimately, it's not our job to work around your IT department for you, so there's only so much we can do. If they won't help you get what you need to do your job, then you've got your own hierarchy to escalate that kind of problem.

Footnotes

1. I have no idea what that is, by the way, but since it's not part of the Python installer you will definitely have to report it to someone other than us. ↩

[n67-exe]

I had the same issue, tried both msix and MS store, both failed to install with the same message. I resolved this by closing all python related applications (like IDEs). Apparently some of them automatically re-enable python's app execution aliases, which (i guess) interferes with the installation process.
Maybe this should be a recommendation on the downloads page?

[zooba]

There's a limit to how much text we can put on the download page before people stop reading it, and I'm pretty sure we're already over that limit. So it's not going to help people - it's just going to make them more likely to miss the most important information.

Windows has historically had a number of bugs relating to maintaining its database of aliases. They've fixed many of them, and I'm hoping they'll keep going (but have been ignoring my reports for the last few years). I suspect in this case the apps in question have run and locked the executables, and so trying to disable them fails and Windows handles that correctly. There's no way for an application to re-enable them.

When the error in this bug occurs, it mentions that another process is using it, which is a better hint than an extra piece of text in the download page would be. The error message could certainly be improved (listing the name of the intended alias would be a great start), but those kinds of improvements get ignored even harder than the bugs.

If the IDEs stop locking the aliases, that would be a better fix, because then everything would just work.

[n67-exe]

There's a limit to how much text we can put on the download page before people stop reading it, and I'm pretty sure we're already over that limit. So it's not going to help people - it's just going to make them more likely to miss the most important information.

I completely agree that there is a lot of text already, maybe creating a separate "Troubleshooting" section would make it clearer. The page already references troubleshooting guides in the documentation, but those are more about making python work after successful installation (maybe that section could be expanded).

I suspect in this case the apps in question have run and locked the executables, and so trying to disable them fails and Windows handles that correctly. There's no way for an application to re-enable them.

The reason i said "re-enable" before is because that's how it feels like, you disable the toggle with no issues, but if you reopen the settings page they are enabled again. Windows probably can't disable them in the first place and just doesn't display any errors in the UI. I don't know for sure but i agree, it makes more sense this way.

When the error in this bug occurs, it mentions that another process is using it, which is a better hint than an extra piece of text in the download page would be.

The error message makes it clear that the alias is being used by another process, however unless you know it's a python alias (and you know what alias is in the first place), it's not obvious how to fix the problem. Also MS Store doesn't show error messages at all (at least i couldn't find it), so improving the message alone won't make a difference for users that install from there.

If the IDEs stop locking the aliases, that would be a better fix, because then everything would just work.

Even if locking is unnecessary and can be fixed quickly, that wouldn't change how older versions work.

[zooba]

We can certainly expand the troubleshooting section you referenced. Feel free to create a PR on the main cpython repo and tag me (no need for NEWS files for doc updates).