Below is the error I get when I run pip
:
serkan$ rm -r mysite
serkan$ pwd
/Users/serkan/Desktop/Python Folder
serkan$ virtualenv mysite
New python executable in mysite/bin/python
Installing setuptools............done.
Installing pip...............done.
serkan$ source mysite/bin/activate
(mysite)serkan$ pip install pinax
-bash: /Users/serkan/Desktop/Python Folder/mysite/bin/pip: "/Users/serkan/Desktop/Python: bad interpreter: No such file or directory
(mysite)serkan$ python pip install pinax
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ python pip install Pinax
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ python pip install Pinax
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ python pip install Pinax
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ python pip
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ pip
-bash: /Users/serkan/Desktop/Python Folder/mysite/bin/pip: "/Users/serkan/Desktop/Python: bad interpreter: No such file or directory
(mysite)serkan$ pip install Pinax
-bash: /Users/serkan/Desktop/Python Folder/mysite/bin/pip: "/Users/serkan/Desktop/Python: bad interpreter: No such file or directory
(mysite)serkan$
Create your virtualenv environment within a path without spaces. This is why it is happening:
When you create an environment, it sets up a bin
directory. In that bin
directory are all the executables relating to the environment. Some are scripts. As you may know, hashbangs are used to tell the system what interpreter to use to run the script. You may see this at the top of scripts often:
#!/usr/bin/env python
If the script is at /tmp/test.py
, that tells the system to run this command to execute the script:
/usr/bin/env python /tmp/test.py
In your case, virtualenv is creating scripts like this:
#!/tmp/oh no/bin/python
When the system tries to execute that, it will try to execute the command /tmp/oh
with the arguments no/bin/python
and /tmp/test.py
. /tmp/oh
does not exist, so it fails.
For those running into this issue, I discovered that the length of the path could cause issues as well, without using any spaces (Ubuntu 12.04):
virtualenv /home/user/some/very/longer/path/without/spaces/etc/venv
failed, while
virtualenv /home/user/some/very/long/path/without/spaces/etc/venv
worked just fine, see Alex's comment below
pip
command won't work if:
pip
on Ubuntu, use command sudo apt-get install python-pip
or sudo apt-get install python3-pip
) If you can't rename folders or change path for some reason, goto yourvirtualenvfolder/bin
(using cd
command) and then try ./python pip install packagename
.
icktoofay is correct about the cause.
To use pip with virtualenv in a directory with spaces, edit /path/to/env/bin/pip
, replacing the shebang at the top with #!/usr/bin/env python
(or #!/usr/bin/env pypy
if you're using pypy).
Note that virtualenv changes your environment such that /usr/bin/env python
refers to the python
defined by the virtualenv.
On Python 3.7 I didn't have any issues with this but when I had to use Python 3.6 I did have an issue. The most easy work-around I found on Github was this:
Instead of:
pip install -r requirements.txt
I use:
python env/bin/pip install -r requirements.txt
So you actually directly point to the pip file within your virtual environment directory. Of course you need to activate it first before trying this. Hope this helps someone who comes here!
I got the same error in RedHat
. Python 2.7.3 is configured and made by myself.
[root@Ifx installer]# pip install Django
-bash: /usr/local/bin/pip: /usr/local/bin/python2.7: bad interpreter: Permission denied
Solution: In /usr/local/bin/pip
, replace first line #!/usr/local/bin/python2.7
with your actual Python path #!/root/installer/Python-2.7.5/python
I had a very similar issue on my Windows 7 machine and struggled couple of days with that. Both paths, to my python distribution and to my VE had spaces in it. Couple of months before it worked fine. I found the following note on virtualenv website:
**Windows Notes**
[...] To create a virtualenv under a path with spaces in it on Windows, you’ll need the win32api library installed.
The following steps lead me to success:
So at least the Anaconda (python) installation simple, non space-pollutted path was crucial . Maybe win32api installation was also important. Not sure.
I found this from a Google search while experiencing the same problem and found this to be very useful. virtualenv
now has a --relocatable
flag that will rewrite the shebang command to #!/usr/bin/env <the_python_version_you_used_to_create_the_virtualenv>
. It does come with some caveats, so be sure to read the documentation to understand the implications:
https://virtualenv.pypa.io/en/stable/userguide/#making-environments-relocatable
You need to use the same syntax to relocate the virtualenv as you did when creating it, otherwise the python version may be overwritten. This will work as expected...
virtualenv --python=python3.5 env-test
virtualenv --relocatable --python=python3.5 env-test
whereas this will result in #!/usr/bin/env python2.7
(at least on my local environment)...
virtualenv --python==python3.5 env-test
virtualenv --relocatable env-test
For my case, deactivate the environment and source bin/activate
again works.
It seems my folder content has same subfolder names as generated by virtualenv
, such as bin, lib etc. And after copy in my files, reactivate the environment let virtualenv
to update new information.
If it's on windows, it can be caused due to dll changes(by other software) Installing openSSL would fix it. https://slproweb.com/products/Win32OpenSSL.html
It will automatically renew dll to its newer versions.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.