@steve.dower I’ve created a tiny PR to fix up some missing slashes in the docs. I could technically merge it myself, but I’ve left you as a reviewer as it’s a long time since I did anything in the repo – so just in case. If you’re happy, I’ll merge.
1 Like
Personally I’m kind of glad it doesn’t. It makes a huge number of aliases that I’m never going to use and don’t need on PATH.
I’m also not sure presenting such a wide range of options is good for new users?
I think it would both be simpler and more accurate to say it can be launched with py -<version>. This should work even if the user hasn’t added the global shortcuts folder, is using the old py launcher[1] and/or has a venv activated.
Except when the registry entry couldn’t be written due to an existing install. ↩︎
Someone’s kindly merged it already
That’s a good point. I’d got the impression that we were intended to use the aliases now, and py was more for compatibility. Certainly, making the aliases as prominent as they are (a dedicated column in py list, the message about putting the alias directory on PATH after every install…) gives that impression. I’d be very glad if that isn’t the case. I know I was one of the people who argued strongly that the py launcher couldn’t be removed, but currently it definitely feels like it’s not the encouraged approach.
Let me change my position - I’d prefer it if the messaging were more consistent with the idea that the aliases are optional, in the same way that having python on your path has always been on Windows.
So I’d propose:
- Get rid of the message about adding the alias directory to PATH. Put that in the documentation, and leave it at that. If we could have an “add aliases to path” checkbox when installing the manager[1] then I’d be OK with that, but my impression is that we can’t do that with a MSIX.
- Remove the messages about the aliases which you get when you install (the ones that say things like
python3.13will run Python 3.13). - Replace the column showing aliases in
py listwith something else that’s more generally useful - I’d suggest thesys.prefix.
Not when installing runtimes! ↩︎
Both of these don’t line up with someone using a pristine/unmodified Windows installation.
At the terminal, running python or python3 will install the Store version, which up until now, would also add the versioned python executable (python3.13). So, if you haven’t dabbled with App execution alias settings, those are behaviors that are “normal”.
If memory serves, in one of the threads regarding the then new installer/manager, @steve.dower had stated the number of installs due to those aliases where quite large. So I suppose it really is just a matter of perspective.
Some developers did not like using the Store version due to slight differences in certain edge cases, but with the new manager, those differences will be gone as the actual Python installations are same regardless of source.
Please note, I’m not suggesting that any functionality gets changed here. All I’m suggesting is that the command output be toned down a bit, to not make it seem like having the versioned aliases is required.
The new manager will still install the versioned executable, but you’ll now need to add the location to PATH manually. That’s a regression, but (apparently) it can’t be helped. Luckily, the python and python3 executables (which I suspect are far more commonly used) are available without a manual PATH setting.
True. But that doesn’t mean that those developers want to buy into using the versioned aliases rather than the py launcher. My only complaint here is that the program output makes it seem like the aliases are the officially preferred approach, and I would like that message to be toned down.
To be clear, I think it would also be simple enough if it said to launch with python3 or python3.13[1] if they were guaranteed to work. The installer knows the folder isn’t on PATH and that they are unlikely to work, so it should suggest something that it knows will work rather than telling the user to jump through the extra hoop of manually modifying PATH when they might not even know what PATH is.
If
python3is already used by a newer Python. I don’t believe the user needs to be told about the other aliases unless they look for them. Mentioning thepythonwaliases in particular could end up being more confusing than helpful. ↩︎
2 Likes
I’m happy to let others argue about behaviour for a while (my preferences are obvious, right now, as I’m the only one who’s coded them up 
), but I do want to address this:
Unfortunately, yes, to all of the above.[1] We can’t modify the user’s registry on install, and can’t clean it up on uninstall. The best we can do is to modify it on first use, but that then results in an impactful system change with at best one printed message that any user is likely to ignore.
Printing the message with the directory to add at least makes the user feel responsible for adding it, and since you can remove the install manager without removing your installs (in fact, we have to allow this, since we can’t clean up runtimes when you uninstall the manager either), the modified PATH would still work just fine (while py, python and pymanager commands would not, since they were uninstalled).
The uninstall --purge option was originally there to help me test stuff, but it also doubles as “easy way to clean up before you uninstall the install manager”, as it will also clean up the Start menu and the Add/Remove Programs entries (each runtime appears there and can be uninstalled, as long as you still have the install manager present).
So it’s still just an unfortunate situation, driven by limitations of the platform/installer technology. I’m not against changing it, but really the only viable change that will cause fewer problems is the suggestion to hide the aliases and push people towards py -V:..., unless they read the documentation (but more likely they’ll figure out py list -f {prefix|exe} and start hard-coding paths, which is also fine, but not intended). I think anything else will lead to more surprises and “corruption”.
If one day an MSIX is allowed to run extra steps on install or uninstall, this would be one of the first things we add. (Currently, it’s available to certain game studios who want to install anti-cheat drivers. I asked for access for us, but was rejected. They’d rather remove the feature entirely than see it gain use.)
Though I’d actually be happy to automatically add this directory to PATH, unlike the old installer, which would add multiple directories to PATH and inject various DLLs into other applications search path (equivalent of setting
LD_LIBRARY_PATHon POSIX, to give an idea of how bad an idea this is). The new directory is safe, as it only ever contains the aliased executables. ↩︎
1 Like
Hi, I tried to use pymanager a little bit on Friday. I couldn’t figure out if it was PEBCAK or a bug, but I couldn’t figure out how to get invoking python to launch 3.14b1t. I tried creating a py.ini file but that didn’t seem to do anything.
That said, it was very easy to install and launch it using py -3.14t.
Was this in a virtual environment, or did you want for the ‘global’ python alias to run the free-threaded build?
A
The global alias.
Did you check what was set up in the “App Aliases” config? Based on my experience, there should be two for python.exe - one is the old Store launcher, which should be disabled, and the other is a new one, added by the manager, which needs to be enabled.
@steve.dower - I thought the manager alias was supposed to be enabled automatically. If it’s not, is that because the store one was disabled? Because if so, it’s starting to sound like more people than we’d anticipated have disabled the store alias, and that could be an issue.
And yes, I know this might come under the heading of “we can’t do anything about that”. But frankly, if we can’t reliably provide a good experience for people using the python command because Microsoft hijacked that command to launch the Store application, we should stick to the py launcher as the recommended solution. We can put a python.exe command in $env:LOCALAPPDATAPython` alongside the versioned commands, and inform people that they need to add it to their PATH. This is no worse an experience than the old MSI installers, and honestly feels like a “better the devil you know” solution. (Sorry, rant over).
1 Like
I still think that there should be a command to do this and another to enable long paths. Ideally, the one for adding to PATH should have a way to choose, if you want to add it to system env vars (%USERPROFILE% is expanded there so it would work) or user env vars (with the former requiring elevation, same as long path enabling). You did mention in the PEP thread that you’ll probably have to add a “system command” at some point and I feel like the feedback here suggests that it would be a good idea. You could then mention the appropriate command in the tip about having to add the entry to PATH.
For clarity, I don’t personally need it since I will use Chocolatey package for pymanager[1] which does both of these for you but I do think it’s important for users to be able to do this more easily than by going through few layers of GUI that they may have not seen before. There is some basic documentation of how to do this in Python’s Windows docs but I don’t think that’s really good enough. It’s also going to be annoying to everyone who helps people out since, rather than just say “Oh, just open command prompt as admin, run py system configure and reopen your terminal window” (or similar), they’ll have to explain how to do this step-by-step through GUI (or give them suspiciously looking long script that can do both of these for them).
disclaimer: I maintain that ↩︎
1 Like
Another alternative would be for pymanager to check (at some appropriate point) that the Microsoft Store app aliases are disabled – if so, it could print more explicit guidance to the user on re-enabling the PyManager ones. I don’t know if this is possible under the MSIX execution model, though.
A
This is possible, but only when you actually launch it. So if you can’t launch it, then you’ll never see it and will still be stuck. Definitely possible, my only hesitation is adding even more console messages - perhaps it needs to actually refuse to function until the user has fixed it, so they won’t ignore the messages, keep failing, and then complain without wondering why?
Yes, definitely possible. It would still leave the user responsible for removing it later if they want to, but I don’t mind that provided they’ve taken an explicit action (beyond a basic checkbox, like in the old installer).
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.)
I thought I already responded to this? Yes, once the user has said “I don’t want a python.exe alias” then they won’t get one, but if the Store one is in place then PyManager will take it over.
This is incorrect. We can’t reliably provide a good experience for users who tried to work around it (correctly, unfortunately, since if they’d just deleted the aliases then I’m pretty sure they’ll come back with the new app). The experience is just fine otherwise. It’s only reasonable to assume that a user who has modified their system settings once can modify them again, but we shouldn’t require users who never touched them to have to figure out how to touch them now.[1]
I have always suggested that py be the usual command for users, but python is specified as the command to show users when instructing them to launch Python. Users who prefer py need to know to translate that, just as users who need python3 also need to know to translate it, but I’d also like it to just work if possible. If that means it only works for people who didn’t modify their own settings to disable it, so be it.
By the way, there was never any need to disable those aliases, unless you explicitly wanted python (no arguments, no stream redirection) to give you an error. Installing with the normal installers and adding to PATH would overrule the redirector, and installing from the Store would override the redirector, and activating a venv would overrule the redirector. You’re putting a huge amount of weight on users who modified their system in a way they didn’t need to, and I will strongly resist sacrificing everyone else’s good experience because of those users.
And I know the lack of command to add to PATH goes against this, which is why I’m leaning towards having it. I just haven’t figured out the design yet, and it’s been the weekend, which is why it still isn’t done since ~4 days ago… ↩︎
2 Likes
I can’t speak for others, but I didn’t realise that this was the case – I disabled them as having the store pop-up was sufficiently annoying that I found the relevant setting. I’d support more documentation here, but there’s always the challenge that people don’t read things on the internet, and that due to the limitations imposed by the OS, it doesn’t seem that there are good technical solutions other than directing users to the settings and saying which bits need to be toggled.
As has been mentioned, this is only a transitional problem, and only needs to be fixed once, so having a quick set of instructions we can link to on the official docs should be useful.
A
3 Likes
You did, but your explanation was unclear to me and I asked for clarification, which I don’t think I’ve had yet. We’re talking past each other, though, so see my comment below for a (hopefully) better explanation of the problem I have here.
I’m afraid I dispute that. You’re putting a huge amount of responsibility on the user who has “modified their system settings” to have known what they were doing and the implications of what they did.
I’m still not clear what changing the little radio icon next to the Store python.exe app alias does. I changed it because when I typed python on a clean Windows PC, I got the store popping up and I didn’t want that. So I googled and found some people saying “go into app aliases and change the setting to “off””. That’s what I did and it fixed my problem. I didn’t know that it wasn’t necessary, as you suggest. I didn’t think of it as saying “I don’t want a global python alias”. Based on the (essentially non-existent) research I’d done, I though of it as solely “make the Store stop interfering with my command line experience”. Since then, many years have passed, and I had essentially forgotten that I’d even made that change - because it did what I’d expected of it.
I doubt that I’m the only person who has done things like that.
Now, with the new manager, it’s behaving weirdly, not doing what it’s claimed to do (install Python so that the python command works). And I don’t think it’s fair to say that this is my fault, because I didn’t do enough research all those years ago and remember the complete implications of the setting change I made.
I do agree that the situation will be much cleaner for new Python users, and we don’t want to compromise that experience. However, we have to look at the transition experience for all the many millions of existing Python users, and make that smooth, as well. I’m not suggesting that everything should work like magic, but I do think that we should be documenting how to navigate smoothly through the transition. That is very much why I’m posting my experiences - I can hack my way to something that works, but I don’t want that to be the “normal” experience, so I’m hoping that we can document recommended steps to take when migrating, in such a way that people who follow the docs will have a smooth experience.
At the simplest level, such a document could say “Uninstall Python totally from your computer, clear all registry entries, reset the Store app alias, and install from scratch”. That works (I know, because it’s what I ended up doing in frustration over the weekend), but it seems like it should be a last resort, so if there are simpler paths that could be tried first, let’s document them.
In that context, I don’t believe that “people who switched off the Store app alias without really understanding the implications” are an ignorable subset. If all we need to do is say “re-enable the App alias for the Store, and then installing the manager will replace it with one that runs Python” then that’s great. But your previous answer made it sound like if you ever disabled the store alias, that was it and you couldn’t go back:
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!
Was I reading too much into that statement? If so, that’s fine, but either way, can we document what people should do, and not assume that they understood all of the implications when they switched the alias off all that time ago?
I think I got confused here, as “disable it” seems to be referring to python, not to py. I thought you were saying that you felt that python was the one that had to work, and people who wanted py are the ones who might need to do some work themselves? Or did you mean it the other way around (that as long as py works, you’re happy, and if people need to do settings changes to ensure python works in non-default installation scenarios, then you’re OK with that)?
Anyway, the point here is more about consistency for me. If the manager says that python will work, then it should. If it can’t guarantee that, then either it should say how to ensure it does work (like it does when saying you need to add the directory to PATH for the versioned aliases) or keep silent (probably best for python, as it seems like there’s too many ways the user can have caused issues).
I didn’t mean to give that impression. I’m simply asking that we give better advice this time to people needing to deal with app alias configuration, compared to what they got[1] when the Store app first appeared and gave them confusing behaviour for the python command. That does indeed include giving them help dealing with the consequences of the previous advice they followed.
mostly not from us ↩︎
4 Likes
From memory pymanager launches on first installation, so would it be possible to check then?
Strictly speaking it’s py-manager that launches, which is also what you get from the Start menu for Python Installation Manager, but you can’t launch it from the command line. Not that that really matters, but yes it could, but that would rely on users reading the message and not immediately dismissing it. Honestly, I don’t think that bet is worth taking.
How’s this: https://docs.python.org/dev/using/windows.html#troubleshooting
1 Like
Yeah, you’re not, and the UI really doesn’t help explain what the OS thinks is going on (I’ve been complaining about this UI for years to no effect, though I have some more projects on side now so we might start getting some improvements).
So it’s not a fair assumption that someone who modified their settings once can do it again, but what’s the alternative? Short of building a GUI app that isn’t Python that gets launched when you launch Python (install manager) which exists solely to provide a better UX for Windows features than Windows itself provides (volunteers welcome), anything else is going to be a printed console message that directs to our own help info, and will still be overlooked in favour of Google or ChatGPT or some Youtube video (did you notice that message, which is already there?).
There’s a limit to how much hand holding we can do, especially if we want to maintain any semblance of compatibility (that GUI app has to still work on Win10, and across all Windows updates…). We can’t even give the exact name of the “Installed apps” settings page because it changes so often. So as much as I’d love to provide correction for all the bad advice out there on the internet, it’s pretty hard, and for now I’ve labelled it “too hard for me personally” (though I do intend to make a video on using the install manager, after we’ve figured out how you actually do use it, which becomes a recursive problem if we rely on existing information on the internet to guide the design).
2 Likes