There are builds for Windows in the repository. There are a huge number of builds for different systems.
But the funny thing is that such portable windows builds exist officially
https://www.python.org/ftp/python/3.13.0/python-3.13.0-embed-amd64.zip
https://www.python.org/ftp/python/3.13.0/python-3.13.0-embed-win32.zip
https://www.python.org/ftp/python/3.13.0/python-3.13.0-embed-arm64.zip
https://www.python.org/ftp/python/3.12.7/python-3.12.7-embed-amd64.zip
https://www.python.org/ftp/python/3.12.7/python-3.12.7-embed-win32.zip
https://www.python.org/ftp/python/3.12.7/python-3.12.7-embed-arm64.zip
etc
Thanks. I will keep trying and I will try this. I now understand that each venv is meant to have its own interpreter, that means I am a lot more clear now on what I should expect.
I am not sure if I explained what the problem is well enough here, but the problem is not just the error. The problem is all these installs that PyCharm hallucinated into existence. Notice how the same Python exe file is labelled with multiple different versions. I want to get rid of all those. I also want to get rid of the ones which point to a file which no longer exists. How do I do these things?
And lastly, concerning “install for all users” (not said by you specifically, but by others), I did this, it installed directly to C:\python313, I thought great, it installed for all users. However, when I run pip and forget to elevate to administrator, it installs to what appears to be a local python 3.13 install (in AppData), which I didn’t install at any point. So now I am going to have things up in the air because if something runs without the permissions for whatever reason, it will modify some local install that again seems to have been hallucinated into existence somehow, and it will do so quietly. Then, I will have lots of problems trying to use imported modules. This is pretty similar to the exact situation I had when I first asked here. We had competing installs, and it wasn’t clear what modules were installed where, where each install was expecting these modules, which installs under which environments had access to these modules, etc, etc, etc.
So in that sense, I’m very lost. Is the “install for all users” supposed to install to AppData? Did I interpret something wrong?
You still have misunderstandings.
Python is primarily an interpreted language. .py files are not .exe files and they are not executables. You need an interpreter. PyCharm is asking you which one you want to use.
It’s normal for PyCharm to offer to run a python source code file with any of the python interpreters that you have added to the project.
Every time you install a new python and use it in PyCharm it is remembering that and offering it as an option to use again. It might keep showing interpreters that you added and then later removed.
1 Like
Yes, I am aware that exe is the interpreter and .py (which is really just a text file but with a .py extension) is what gets ran (i.e. interpreted) by it. It does make sense as you say to consider that perhaps it somehow is referencing old installs, although a few of these versions I have never installed on any machine at any point, so I really don’t know where it thinks those are from.
They might be from virtual environments.
1 Like
Perhaps. Its possible that while clicking through the confusing menus I inadvertently installed many different versions. None of them work anymore when I select them, for reasons ranging from “SDK seems invalid” to “no python at file_path.exe” to “invalid python interpreter configured for this project”.
Within PyCharm these interpreters are basically just references. They store filepaths under names. So feel free to remove them, it shouldn’t delete any python interpreter without prompting you specifically.
(Though this is based on my experience of what similar tools do, PyCharm might be terrible, I’ve never used it, but I see it recommended a lot so I doubt it)
Have you seen xkcd: Python Environment ?
It reminds me of your situation. You’re not the first and won’t be the last.
I avoid these problems by using virtual environments for every project, and managing multiple python versions outside of the system (tools like UV make this easy). I never install anything to the system python. As far as I’m concerned the system python is only for my operating system (on Linux), I’d rather not have it installed on Windows at all.
If I need a new (whoops wasn’t finished) python version. I’ll download that version of python (again, uv makes this easy) and create new virtual environmenta using it. Existing virtual environments can continue using whatever version of python they have.
If I want to, I can explicitly upgrade a project to use a new version of python by recreating its virtual environment
2 Likes
Right, sure I’d love to do that. I have just not felt secure doing this since I don’t quite get the nuances yet, but it is getting a bit better. I’m mostly annoyed that the install for all users environment requires me to start everything with admin privileges or else it quietly fails and uses some local installation (which I insist I did not intentionally install, something somewhere has decided to install it for me without my knowledge), meaning that when I run a command now, I don’t know from which install it is pulling modules from. I just know from experience that months/years down the track this will just result in the identical situation I came here with.
That is annoying. I’d get rid of the system-wide / any user python in C:// I don’t want python code running with admin privileges by default.
You said you accidentally had multiple users… Any chance you can just remove one of them and only have one?
So you don’t want me to have a system-wide install? I can do that, although following advice of people here I deleted all my installs that I could find (although traces are left behind in really tough to find places), and installed a system-wide install.
The problem, as you point out, is that writing to the directory where system-wide Python installs to by default requires admin privileges, which I have to manually grant every single time I want to do something such as pip install.
I’d rather the pip install give an error than quietly fail and install to a local installation instead, and act like it didn’t just throw my entire setup into jeopardy.
I can look into removing the other accounts from the system again, although since I made this mistake when I first setup the PC, the first account that I attempted to set up (never actually finished setup because I realised I made a big mistake) unfortunately has some kind of TrustedInstaller-like status that seems to make it quite difficult to get rid of, presumably since it is the account that was initialised in some capacity upon first boot, making it “special” somehow.
The last thing I’ll say till I’ve worked up the courage to try some of these things more thoroughly and have some news is that I wish this was a Python specific problem, but it isn’t. My NodeJS - identical problems. Visual Studio C/C++? identical problems. It seems that these applications simply aren’t transparent enough with regard to where they expect certain files, modules, data, environment variables, etc, to be located, and how they should be set. And then when they are not set as expected, they work around the problem with a bandaid that will then stab me in the back in a few months time when it wears off.
I’m not a programmer, but having a day of trying (once again) to get my win 11 pc to find python properly, I have found a couple of things that make it better, but not perfect. 1) Start CMD in Administrator mode, or it won’t find it at all. After that, if you want to call python more than once, you will have to start a new instance of CMD. 2) If you have a version in Windows\System, and CMD opens there, it will try to use that one. Try changing directories to the one that you are trying to work with. 3) This is a sneaky one. In the PATH variable, if the entry for WindowsApps is listed before the path for python, it will not work. It seems they have a bogus entry for python.exe that is only something to do with the Windows store. Any search by CMD for python hits that first and takes a nose dive. To fix: just edit the PATH to move the WindowsApps entry to the bottom of the list. 4) I’ve seen some fixes that involve separating the different python versions in ways that keep them in line, but it is more complicated than I want to get into. 5) I also duplicated all of my path alterations in both the user and system areas. I can’t promise that any or all of these things will fix your system, but at least you can try a few things that seem to have straightened my system out a bit. I think #3 may just be the most effective one that I have tried. Good Luck.