I understand that the fact that having to type "python3" or "pip3" instead of "python" and "pip" respectively is an annoyance at worst, however it makes me paranoid that other things that I install to my vscode will also have to be run differently. Every other programmer that I watch doesn't have to do so.
zsh: command not found: python
Could it possibly be an issue with my pathing of my downloads?
This, of course, has nothing to do with VSCode and everything to do with the install of Python on your machine. However, it is strange to not have the Python available with just python at the shell.
In any case, one simple way to solve this issue is to open (or create) ~/.zshrc and add the following line:
alias python="python3"
This is a common thing in particular for macOS users, where python often points to the pre-installed Python2.7.
Restarting terminal/VSCode after making this change should fix your issue.
Today when I tried to run simple code on Sublime Text 3, the following message appeared:
Python was not found but can be installed from the Microsoft Store: https://go.microsoft.com/fwlink?linkID=2082640
And when I type Python in CMD, it opens the Windows Store for me to download Python 3.7. This problem started today for no good reason. I didn't change or download anything about Python and already tried reinstalling Python, and the Path environment variable is correct.
Use the Windows search bar to find "Manage app execution aliases". There should be two aliases for Python. Unselect them, and this will allow the usual Python aliases "python" and "python3". See the image below.
I think we have this problem when installing Python because in a new Windows installation the aliases are in the ON position as in image below. When turned on, Windows puts an empty or fake file named python.exe and python3.exe in the directory named %USERPROFILE%\AppData\Local\Microsoft\WindowsApps. This is the alias.
Then Microsoft put that directory at the top of the list in the "Path" environment variables.
When you enter "python" in cmd, it searches the directories listed in your "Path" environment variables page from top to bottom. So if you installed Python after a new Windows 10 install then get redirected to the Windows Store, it's because there are two python.exe's: The alias in the App Execution Alias page, and the real one wherever you installed Python. But cmd finds the App execution, alias python.exe, first because that directory is at the top of the Path.
I think the easiest solution is to just check the python.exe and python3.exe to OFF as I suggested before, which deletes the fake EXE file files. Based on this Microsoft Devblog, they stated they created this system partially for new Python users, specifically kids learning Python in school that had trouble installing it.
Creating this alias was to help kids just starting Python to install it and focus on learning to code. I think Windows probably deletes those aliases if you install Python from the Windows App Store. We are noticing that they do not get deleted if you manually install from another source.
(Also, the empty/fake python.exe is not really empty. It says 0 KB in the screenshot, but entering "start ms-windows-store:" in cmd opens the Windows App Store, so it probably just has a line with that and a way to direct it to the Python page.)
Finally, as Chipjust suggested, you can create a new alias for Python using something like DOSKEY as explained in this article for example:
How to set aliases for the command prompt in Windows
The main problem here is that the order in the path calls the windows from top to bottom, and that there is python.exe in %USERPROFILE%\AppData\Local\Microsoft\WindowsApps which is called first if there are no other python.exes in the PATH above that line.
To ensure that the correct python.exe is called, add the Python interpreter installation folder (containing python.exe) to the PATH, above %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
Here is an example:
To get to this location, click "Start" → start typing "Env" → Select "Edit the system environment variables" → "Environment variables" button → Select the entry for "Path" in the upper list → Click "Edit".
Python components should be at the top, as in step 5. If not, move them up by pressing the button in step 6.
If the Python interpreter is already installed, then go to Apps & features from settings, select Python, and then select modify.
Again select modify and select Next:
Then this window will appear:
Select "add Python to environment variable" and click on the install button. Then again go to apps & features, click modify and click Repair.
Now go to CMD and type Python.
Problem solved.
This is a PowerShell script that does the magic.
Remove-Item $env:USERPROFILE\AppData\Local\Microsoft\WindowsApps\python*.exe
I had problems with this as well, where Windows didn't recognize Python or Anaconda in a double click or cmd (command) prompt.
Problem: unable to import libraries in "python" cmd in Windows. Instead the Windows "python" cmd took users somewhere they don't want to go.
Problem Cause: In Windows "Environmental Variables", Windows adds a python.exe and python3.exe (I don't know where these link to) in the "%USERPROFILE%\AppData\Local\Microsoft\WindowsApps" directory.
Solution: I tried deleting the python*.exe files in the WindowsApp directory, but Windows wouldn't allow it, so I opened a command prompt in the "%USERPROFILE%\AppData\Local\Microsoft\WindowsApps" directory and typed:
del python.exe
del python3.exe
Then I created an environment variable linking to the installed Python interpreter link. In my case, it was C:\Anaconda3; C:\Anaconda3\Scripts, and some others for good measure.
Because this is a common issue and this appears to be the canonical question, I want to try to give a complete overview of The Python 3.7 Windows Store Fiasco (TM).
Why is it possible for this to happen?
A convergence of two things: the previous introduction of the Python Launcher for Windows in 2011 (hereafter py), and a Windows 10 update in May 2019 that was apparently intended to make installing Python easier for Windows users.
Oops. Turns out that installation path isn't great; it bypasses the "lengthy" setup wizard... which contains some options that some users find very useful. It caused other issues, too. Not to mention that it just works in slightly non-standard ways, has limitations on file system access because it's a Store app, initially couldn't itself be launched by py....
Okay, but why do those factors result in the problem?
Since the introduction of py, by default, Windows Python installers do not add the new Python install to the PATH. Why? Because the entire point of py is that it uses its own logic to find a Python installation, based on some combination of command-line switches and possibly the source file's own shebang line. Now your source files can be associated with py instead of any particular python.exe, and you can get Linux-like behaviour when double-clicking a file. Meanwhile, by running py at the command line, you have easy access to whatever you need, and you don't have to think about which version of Python was installed most recently. So there's seemingly no good reason to put any of those Python installations on the PATH. It only risks confusing you when, for example, the most recently installed version isn't the most up-to-date one. Right?
In the update, Windows 10 put a "python.exe" into a Windows Apps-related folder, which is a wrapper app to open a Microsoft Store link. The idea is that it's on the PATH, but way near the end; so if you have an installed Python, it gets used, and otherwise the wrapper is invoked and helpfully prompts you to install Python - so that you can actually run that random, totally trusted .py file your friend sent you on Discord.
And it would work perfectly, if your installed Python were on the PATH.
Oops.
(But, you know, py had been introduced around 8 years prior. You'd think someone at Microsoft would have been aware of the potential issue. Maybe instead of a special shortcut link, they could have made an actual script that checks for the presence of C:\Windows\py.exe or something.)
So what are my options?
You can check the option to add new Python versions to the PATH when you install them, and deal with the fact that python at the command line means a specific one of them. If you need to change that, you can manually tweak your PATH variable.
You can just manually tweak the PATH variable after the fact. (or "Modify" a Python installation to fix it.) This is covered in several other answers.
Independently of that, you can disable the wrappers, as shown in the top answer. You should probably do this anyway; seeing python fail at the command line is less aggravating than dealing with a random GUI window popping up and offering to install something for you, especially when you know you have it already.
If you want to keep the PATH empty, consider using virtual environments for your projects. Whenever a virtual environment is active, the PATH is temporarily modified such that python means the Python installation of that environment. It's quite convenient, really.
You might be able to tell your IDEs to use py instead of a specific Python installation, and it might even be helpful to do so. I don't know. I don't use one.
As a person who does Python development in Sublime Text, I know you said the Python interpreter path was correct, but when you install the Python interpreter make sure to tick the option to add Python to PATH.
I had the same issue back in the day till I did this.
You can manually add Python to the Windows path by doing this:
Start the Run box and enter sysdm.cpl
Go to the Advanced tab and click the Environment Variables button
Now you’ll need to locate the relevant Python paths
Here is how a Python application path looks like:
And this is how a Python Scripts path looks like:
Select the Path variable, press edit and add both paths (Python application and Python Scripts)
If it doesn't show, press new instead of edit and fill the New User Variable box
This is how my Variable value looks like:
C:\Users\Ron\AppData\Local\Programs\Python\Python37-32;C:\Users\Ron\AppData\Local\Programs\Python\Python37-32\Scripts
That’s it! You just added Python to the Windows Path.
Source: Data To Fish
So, I had the same problem.
My answer was to add python to PATH not only for User variables, it was there, but also for System variables. And now everything works.
So, I've got the same problem in VENV.
I solved it by typing >> python**.exe**
But to add every time .exe a little bit nervous.
Also try to type python.exe in cmd.
This is an additional note for anyone using pyenv-win: after turning off the application execution aliases, run pyenv rehash. You may also need to close/reopen your CMD or PowerShell window.
I have put together a powershell snippet, which reorders WindowsApps and Python folder so that Python is first. Run this as Admin:
$appsFld="$env:USERPROFILE\AppData\Local\Microsoft\WindowsApps";
$pyPath=(Resolve-Path "$env:USERPROFILE\AppData\Local\Programs\Python\Python*\")
$Env:Path = (($Env:Path.Split(';') | Where-Object { $_ -ne "$appsFld" }) -join ';');
$Env:Path = (($Env:Path.Split(';') | Where-Object { $_ -ne "$pyPath" }) -join ';');
$Env:Path += ";$pyPath";
$Env:Path +=";$appsFld";
[Environment]::SetEnvironmentVariable("PATH", "$Env:Path", "Machine")
Then I can run python just fine:
> python
Python 3.10.7 (tags/v3.10.7:6cc6b13, Sep 5 2022, 14:08:36) [MSC v.1933 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit
Adding a bit to the question. Even when I typed pip freeze, it wasn't showing anything.
Here's what I did:
There were multiple instances for the Python application in /AppData/Local/Microsoft/WindowApps.
I deleted those and then it worked.
Created virtual environment in ~/python/venv/venv_python2 folder.
I can run python in a regular way (for venvs):
source ~/python/venv/venv_python2/bin/activate
python
or I can run python with:
~/python/venv/venv_python2/bin/python
What is a difference between 2 above?
There is no difference.
You can check where python is running from by typing which python in bash. You'll see that it points to your virtual env when you're in it.
The purpose of the virtual environment is to isolate the dependencies inside it so you don't have to worry about knowing the precise path to the correct Python interpreter or the libraries you have installed. So while using the absolute path is technically not incorrect, it completely bypasses the facilities of the virtualenv, and could eventually end up pointing to the wrong location if you hardcode it in a script today, and decide to move, migrate, or refactor your virtualenv tomorrow.
There is a very slight, almost irrelevant difference between the two:
~/python/venv/venv_python2/bin/python specifies exactly which Python interpreter you want to use.
python runs which ever interpreter is found first when examining your path.
One of the things that source ~/python/venv/venv_python2/bin/activate does is that it puts ~/python/venv/venv_python2/bin at the front of your path, so that when you run /-free command, the first place the shell looks is that directory, meaning python will resolve to the one in your virtual environment.
So, the only way your two ways would differ is if something else modified your PATH in the meantime.
I have several packages on my windows python environment and I would like to use them inside Cygwin. Can I setup a virtual environment linked to the files used for the windows' python or do I have to copy the files?
Older Cygwin was written with its stdin, stdout, stderr bound to Windows i.e. it was a Win32 console program. Then it was possible to run Windows version of Python as:
/cygdrive/c/Python27/python.exe
You could even have added /cygdrive/.../Pythonxx to your path variable.
Newer versions are written with implemented their own terminals and when you run an Win32 console app like Python it freezes.
Even running it under "cmd" run inside cygwin won't work.
Half an answer is to run it always in interactive mode, then it works a little. Eg.
/cygdrive/c/Python27/python.exe -i program.py
or just for shell
/cygdrive/c/Python27/python.exe -i
You can try playing around under cygwins options, and change a terminal which it currently emulates, to see whether it will do you any good.
Running Windows version of Python under cygwin, if you have older one, will be like you are still in Windows but using Unix console.
I think that is not something you would like to do anyway,
but mentioned it just in case.
I would like to do just that very much, but well, on newer Cygwins it doesn't work.
Then all modules are still there. And you're still in Cygwin.
To access modules which are in Windows version of Python from Cygwins version you add the Windows site-packages to the Python path variable.
On top of your program do:
import sys
sys.path.insert(0, "/cygdrive/c/Python27/lib/site-packages")
Then you can import them normally. But, this isn't exactly advisable.
For example, all modules that depend on windows paths could have great problems.
Or those written in C wouldn't exactly like been called from Cygwin.
Especially when Cygwin's Python version number and Windows's one aren't the same.
I tried with pyaudio, it collosaly crashed.
Some of them (mostly the little ones) will work just fine.
But, IMPORTANT NOTE here is, depending on the place you insert your Windows site-packages path the directory will be searched.
If you put it in place 0, Python will look at it firstly.
Then, it is perhaps better to use:
sys.path.append("/cygdrive/c/Python27/lib/site-packages")
If some package is packed into an EGG or ZIP archive, you will have to add it separately to the path.
The same goes for subdirectories. You try and keep thumbs up.
If you don't want to do that, you can:
import os
wd = os.getcwd()
os.chdir("/cygdrive/c/Python27/lib/site-packages")
# Your Windows imports here
os.chdir(wd)
Sometimes you will have to do both.
You can add even a check, so that your program works in both environments nicely:
if sys.platform=="cygwin": ...
It will work without a check, but it is stupid to bother Python with twice added same directory into the path.
Copying the packages will save you from these extra lines of code, but the problems I mentioned above will remain the same.
Never the less, if the modules are small, copy them, if not, do as I said, but be aware that it's not exactly something that is supposed to be done.
My command prompt is currently running Python 3.2 by default how do I set it up to run Python 2.7 by default, I have changed the PATH variable to point towards Python 2.7, but that did not work.
UPDATE:
It still does not work. :(
Still running python3 - to be specific it runs python3 when I am trying to install flask - which is what I want to do.
More generally, when I simply type python into the command line, it does nothing.
I get a 'python' is not recognized as an internal or external command, operable program, or batch file error.
No idea what to do.
If you call your Python scripts directly using python script.py then setting the PATH to have the 2.7 directory first should be enough.
If you want to call Python scripts indirectly with the shell, i.e. by writing just script.py or by executing the file from the explorer, you need to set the 2.7 installation as the default program handler for the .py extension. The easiest way to do that is to run the Python installer again and choose the option “make this installation the default”.
Note that with the new launcher, that ships with 3.3+, you don’t need this, as you can specify the version number using a shebang line and the launcher will automatically pick the appropriate interpreter.
Changing your PATH environment variable should do the trick. Some troubleshooting tips:
Make sure you didn't just change the local, but rather the system variable to reflect the new location
Make sure you restarted your CL window (aka close "cmd" or command prompt and reopen it). This will refresh the system variables you just updated.
Make sure you remove all references to C:\Python32\ or whatever the old path was (again, check local and system PATH - they are both found on the same environmental variables window).
Check to see if Python3.2 is installed where you think it is... (just rename the directory to something like OLD_Python3.2 and go to your CLI and enter "python" - does it start up? If it does is it 2.7? or 3.2? If not, you did something wrong with your PATH variable.
All else fails - reboot and try again (you might have some persistent environment variable - which I don't see how that can be - but hey, we are brainstorming here! - and a reboot would give you a fresh start.
If that doesn't work then I'd think you are doing something else wrong (aka user error). CMD has to know where to look for python before it can execute. It knows this from your PATH variable... now granted, I work almost exclusively in 2.6/2.7, so if they did something to the registry (which I doubt) then I wouldn't know about that.
Good luck!
Change the two las lines to you current python desired build path:
Windows Registry Editor Version 5.00
' Extracted from Python 2.7 silent installation By Elektro H#cker
[HKEY_CLASSES_ROOT\.py]
#="Python.File"
[HKEY_CLASSES_ROOT\.pyc]
#="Python.CompiledFile"
[HKEY_CLASSES_ROOT\.pyo]
#="Python.CompiledFile"
[HKEY_CLASSES_ROOT\.pyw]
#="Python.NoConFile"
[HKEY_CLASSES_ROOT\Python.File\Shell\Open\Command]
#="CMD /K \"\"C:\\Program Files (x86)\\Python\\Python.exe\" \"%1\" %*\""
[HKEY_CLASSES_ROOT\Python.NoConFile\Shell\open\command]
#="CMD /K \"\"C:\\Program Files (x86)\\Python\\Pythonw.exe\" \"%1\" %*\""
Could you try this as root:
$ ln -s python2.7 /usr/local/bin/python
Logout & login again as root:
$ python -V
It works for me, hoping the same to you.
Cheers,