We Keep Coding

python3 -m venv .venv Error: [WinError 2]

As the title shows, I get an error when attempting to run python3 -m venv .venv: Error: [WinError 2] The system cannot find the file specified. I am running the command in Bash on Windows. I have python version 3.8.7.
I tried copying "python.exe" to also have "python3.exe" which may be worth noting.
Python is installed here: C:\Users\me\AppData\Local\Programs\Python\Python38
Path includes: C:\Users\me\AppData\Local\Programs\Python\Python38\Scripts
and C:\Users\me\AppData\Local\Programs\Python\Python38\
Any remedies to this issue, thank you all.

Since you are working with windows, you can specify python version with python absolute path as mentioned previously or with python launcher (which is installed with python) with py command.
you can list installed python versions with py -0 then you can get output similar to this:
Installed Pythons found by py Launcher for Windows
-3.9-64 *
-3.8-32
-3.7-64
-3.6-64
-2.7-64
Then you can specify python version you want by typing it as listed.
python3 command is almost used in linux os which have installed python 2.x so python refer to python 2.x and python3 refers to python 3.x.
More information i found from this answer post Link.

PYTHONPATH is not read by IPython when installed via Homebrew

I installed IPython and Python 3 by using Homebrew on a clean macOS Catalina (virtual machine).
$ brew install ipython
As the ipython package is dependent on the python3 package, Homebrew installs ipython and python3 together.
$ brew info ipython
ipython: stable 7.13.0 (bottled), HEAD
Interactive computing in Python
https://ipython.org/
/usr/local/Cellar/ipython/7.13.0 (2,905 files, 21.8MB) *
Poured from bottle on 2020-04-15 at 18:48:22
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/ipython.rb
==> Dependencies
Required: python ✔, zeromq ✔
==> Options
--HEAD
Install HEAD version
==> Analytics
install: 11,543 (30 days), 33,591 (90 days), 98,995 (365 days)
install-on-request: 5,404 (30 days), 15,768 (90 days), 49,364 (365 days)
build-error: 0 (30 days)
I expected that both of these two commands read PYTHONPATH from my shell environment, because ipython works so when it is installed by pip3 install ipython.
However ipython and python3 installed by using Homebrew have different sys.path settings.
$ which ipython
/usr/local/bin/ipython
$ which python3
/usr/local/bin/python3
$ ipython
Python 3.7.7 (default, Mar 10 2020, 15:43:33)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.13.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import sys; sys.path
Out[1]:
['/usr/local/Cellar/ipython/7.13.0/libexec/bin',
'',
'/usr/local/Cellar/ipython/7.13.0/libexec/lib/python3.7/site-packages',
'/usr/local/Cellar/ipython/7.13.0/libexec/vendor/lib/python3.7/site-packages',
'/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python37.zip',
'/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7',
'/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload',
'/usr/local/lib/python3.7/site-packages',
'/usr/local/Cellar/ipython/7.13.0/libexec/lib/python3.7/site-packages/IPython/extensions',
'/Users/oxon/.ipython']
$ python3
Python 3.7.7 (default, Mar 10 2020, 15:43:33)
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.path
['', '/Users/oxon/root-6.20.02/obj/lib', '/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python37.zip', '/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7', '/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload', '/usr/local/lib/python3.7/site-packages']
Q1. Why are they different?
Q2. Is this an expected behavior?
Q3. Why IPython reads PYTHONPATH when it is installed by pip3 install ipython?

It comes down to the following line in the Homebrew recipe for ipython:
bin.env_script_all_files(libexec/"bin", :PYTHONPATH => ENV["PYTHONPATH"])
It creates the /usr/local/bin/ipython script that sets PYTHONPATH to a fixed value that is needed for IPython to work properly (since its modules are outside the default Python module directory) before calling the ipython executable:
#!/bin/bash
PYTHONPATH="/usr/local/Cellar/ipython/7.14.0/libexec/lib/python3.8/site-packages:/usr/local/Cellar/ipython/7.14.0/libexec/vendor/lib/python3.8/site-packages" exec "/usr/local/Cellar/ipython/7.14.0/libexec/bin/ipython" "$#"
It simply overrides your set value of PYTHONPATH. You may modify the script to read:
PYTHONPATH="$PYTHONPATH:/usr/local/Cellar/...
This will make it append to your PYTHONPATH instead of completely overriding it, but the file will be overwritten when the Homebrew package is updated or reinstalled. Therefore, it is advisable to instead put in the IPython startup directory ~/.ipython/profile_default/startup a script, say root.py that looks like:
import sys
sys.path.append('/Users/oxon/root-6.20.02/obj/lib')
When you install ipython using pip, its modules go into the default Python module directory, be it the system one or the user one or the one in the virtual environment, and it is not necessary to mess with PYTHONPATH for ipython to function correctly.
I'd say the answer to Q2 is therefore that it's probably a bug and you may submit an issue with Homebrew on GitHub, although I wouldn't hold my breath given how they treated the same issue with Jupyter.

Q1. Why are they (i.e., sys.path) different?
The way sys.path is populated is typically:
1) the current working directory, followed by 2) directories listed in your PYTHONPATH environment variable, followed by 3) installation-dependent default paths, which are controlled by the site module.
From https://docs.python.org/3/using/cmdline.html : PYTHONPATH: Augment the default search path for module files.
See also e.g.,
https://leemendelowitz.github.io/blog/how-does-python-find-packages.html
https://realpython.com/lessons/module-search-path/
https://learn.microsoft.com/en-us/visualstudio/python/search-paths?view=vs-2019
Therefore, each python installation may have its own sys.path.
In addition, sys.path does not need to be equal to PYTHONPATH
Check in each of the two (or three?) cases also the value and post back:
import os
print( 'PYTHONPATH = ', os.environ['PYTHONPATH'] )
For instance, I have spyder3 and python3.8 under Ubuntu 20.04. When started at the same CLI each has its own sys.path, both "derived" from the same PYTHONPATH.
Q2. Is this an expected behavior?
Yes.
Q3. Why IPython reads PYTHONPATH when it is installed by pip3 install ipython?
Please post the value of PYTHONPATH ($ echo $PYTHONPATH) prior to executing either of the pythons at the CLI. It is not evident that they are or are not reading its value.
Please post back if this helps finding the cause.

Fatal error in launcher: Unable to create process using '"' in python

I had python 2.7 before and then I installed python 3.4.The OS is windows 10
I have renamed
C:\python27\python.exe to python2.exe (when I run python2 --version it shows correct version)
and
C:\python34\python.exe to python3.exe (when I run python3 --version it shows correct version)
I have set the path variable manually and there is no space etc.
I was trying to create a virtual environment and assign python34 to this new environment.
I was going through this SO reference -- Using VirtualEnv with multiple Python versions on windows
prompt>> virtualenv -p c:\Python34\python3.exe casenv
But I got an error--
Fatal error in launcher: Unable to create process using '"'
Do I need to install virtualenv again for python34 or somewhere I need to set virtualenv path for each python installation.
Any help is highly welcomed.

In my case, i had installed python 3.6 and uninstalled python 2.7 when i got this error.
Completely deleting the C:\Python2.7 directory did the trick.

This error is usually caused because of python directory of different versions stored at same location.
i.e in my case I was using python 3.5.X for development and when I updated to 3.7.6 I got this error.
People on internet suggest that it is because of pip but main cause is 2 or more python directory.
The following steps should fix it:
Uninstall previous python version (or use virtual environment if you want to play with multiple python version)
Delete the python directory you are not using (as it causes confusion for terminal to understand which python path it should pick to execute the command)
and this should fix the error of
fatal error in launcher unable to create process using ' '

Pip version: 10.0.0
Python version: 3.6.5 64 bit
Operating system: Windows 7 Ultimate, Service Pack 1, 64-bit
Description:
After upgrading pip to the version 10.0.0 (from Pycharm, that is using pip as a package) any attempts to start updated pip cause an error:
Fatal error in launcher: Unable to create process using '""c:\program files\python 3.6\python.exe" "C:\Program Files\Python 3.6\Scripts\pip.EXE"'
Command python -m pip works as expected.
I found text "Fatal error in launcher" only in executables:
src\pip_vendor\distlib\t32.exe
src\pip_vendor\distlib\t64.exe
and in the pip.exe itself.
After
python -m pip uninstall pip
easy_install.exe pip
error disappeared.
It is interesting, that initially pip.exe had almost the same size as t64.exe, now it significantly shorter.

If someone came after installing a newer version like 3.X and uninstalled the older version, what you need to do is to delete the old version's folder from C Drive.

Clean Fix (Windows)
The fastest way to fix the issue you were facing is to uninstall and reinstall.
Why it happened?
You probably moved the directory where python was installed.
You probably have both environmental variables listed in Environmental Variables.
Things to consider
You can only use 1 active version of python at a time if you use the MSI installer.
If you downloaded the zip file of Python, you can have unlimited versions in your computer BUT you can only have 1 active version under Environmental Variables.
You can always use any version of Python explicitly by writing the direct path to the specific location of the version of Python.

Install Matlab Engine for Python 3.4.5

I need to install the Matlab engine for Python 3.4.5 in an Anaconda environment.
When I try to install the Matlab engine with the following command:
sudo python setup.py install --prefix="/home/<<my user>>/anaconda3"
It creates another folder named python2.7 and inside it creates all the necessary files and folders:
/home/<<my user>>/anaconda3/lib/python2.7/site-packages
When I run which command and the python one they return
which python
/home/<<my user>>/anaconda3/bin/python
python
Python 3.4.5 |Anaconda 4.3.0 (64-bit)
So the system points towards the correct Python version
I even check what version the setup.py finds and it is 3.4
What do I miss?
Cheers,
Dan

I don't know what exactly the issue is, can you import the matlab engine?
If it doesn't work most likely the problem is when you install the engine on a different python environment (in this case the one from Anaconda), you need to link the library from this environment.
On linux you can do:
export LD_LIBRARY_PATH="/home/<<my user>>/anaconda3/lib:$LD_LIBRARY_PATH"
On Mac:
export DYLD_LIBRARY_PATH="/home/<<my user>>/anaconda3/lib:$DYLD_LIBRARY_PATH"
That should work, otherwise you can follow this link.

Trouble creating a virtualenv for python3 on OS X

I'm having a strange problem with a virtualenv I've created for python 3. I went through the usual steps:
$ virtualenv --python=/opt/local/bin/python3.3 .py3
$ source .py3/bin/activate
The problem I'm having is that when I call python --version, it is still reporting 2.7.5, even though the paths all appear to be set up correctly. My virtualenv was created in /Users/barry.flinn/projects/.py3/bin, and I get thes results when I run which python:
$ which python
/Users/barry.flinn/projects/.py3/bin/python
The bin folder has the following python executables:
lrwxr-xr-x 1 barry.flinn obfuscated\Domain Users 9 Sep 23 19:39 python -> python3.3
lrwxr-xr-x 1 barry.flinn obfuscated\Domain Users 9 Sep 23 19:39 python3 -> python3.3
-rwxr-xr-x 1 barry.flinn obfuscated\Domain Users 9100 Sep 23 19:39 python3.3
Clearly, invoking python should give me python 3.3, and yet it still seems to revert to the system python, which is 2.7.5. My $PATH when the virtualenv is active is:
/Users/barry.flinn/projects/.py3/bin:/usr/local/mysql/bin:/opt/local/lib/postgresql92/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/go/bin:/usr/local/munki
Since all of this seems correct, I'm stumped as to what is going on here.
Update:
This reports correctly:
$ env python --version
Python 3.3.2
Which, to me, is slightly more baffling.

If you have a shell alias defined for the python interpreter, it will override the python chosen for your virtualenv. For example:
user#x790:~/temp$ alias python=/usr/bin/python
user#x790:~/temp$ python --version
Python 2.7.4
user#x790:~/temp$ virtualenv --python=/usr/bin/python3 foo
Running virtualenv with interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in foo/bin/python3
Also creating executable in foo/bin/python
Installing distribute.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
Installing pip................done.
user#x790:~/temp$ . foo/bin/activate
(foo)user#x790:~/temp$ python --version
Python 2.7.4
Note that the python version reported was 2.7.4, even though python3 was selected for the virtualenv. Using the env command circumvents the alias:
(foo)user#x790:~/temp$ env python --version
Python 3.3.1
Lastly, you can get around this issue by either temporarily disabling the python alias for a single command or permanently undefining it:
(foo)user#x790:~/temp$ \python --version
Python 3.3.1
(foo)user#x790:~/temp$ unalias python
(foo)user#x790:~/temp$ python --version
Python 3.3.1