Related
I installed virtualenv using the command sudo pip install virtualenv and the installation is successful. Later, when I type virtualenv, I get the error message as following, -bash: virtualenv: command not found
The virtualenv is installed in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages. I see the similar questions in the forum with no definitive answers.
Python is in the location /usr/local/bin/python and I have version 2.7.9. I get the following using ls -l command,
Why do I see the virtualenv is not found and how to solve the issue ?
UPDATE:
I use the command
ln -s /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/virtualenv.py /usr/local/bin/virtualenv.py to put the virtualenv.py
inside the /usr/local/bin folder. Previously, I only did the same for the virtualenv file. Now, when I put the command virtualenv in the terminal, I get
-bash: /usr/local/bin/virtualenv: Permission denied.
I later use
sudo ln -s /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/virtualenv.py /usr/local/bin/virtualenv.py
and the say message keep showing. which virtualenv still returns nothing.
Pursuant to #Jason's suggestion, try making the symbolic link for virtualenv in the /bin directory like so:
ln -s /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/virtualenv /usr/local/bin/virtualenv
Why don't re-install virtualenv? Also try to use the latest version of pip (sudo pip install -U pip).
Not sure if the answer will be useful to you, as i see the question is a few month old, but maybe it will be helpful for others.
I encountered the same problem, after installing python3.5 and pyCharm on my Mac. I moved the 3.5 folder from /Library/Frameworks/Python.framework/Versions/3.5 to /System/Library/Frameworks/Python.framework/Versions/3.5, following this guide, after disabling the System Integrity Protection first with reboot into recovery mode (boot with ctrl+R), and executing csrutil disable in the terminal. After reboot it was possible to move the python3.5 folder, and then i followed the guide, and everything worked like charm. In pyCharm i could choose the version 3.5 from /System/... instead of /Library/... (however, i still left a soft link in /Library/... to the /System folder where the python3.5 now was, just in case), and after adding the path to my zsh i could execute pip3 install virtualenv. So far so good.
Next, i tried to create the environment with virtualenv -p python3 env, and here i had the same problem as you. It seemed like the path could not be added somehow. Initially i also tried to look in the /System/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/ and include it in the $PATH, then also create softlinks to virtualenv.py as you tried too, but finally found that although all the files are in the site-packages folder, the actual executable was in /System/Library/Frameworks/Python.framework/Versions/3.5/bin/virtualenv. As the path there was included in my $PATH, i have no idea why it did not execute when typing virtualenv -p python3 env, even with sudo as you tried too, but once i typed the full path /System/Library/Frameworks/Python.framework/Versions/3.5/bin/virtualenv -p python3 env, it worked like charm again.
I still have no idea why, but it worked and now i can move on :)
Hope it helps, and hope someone can explain this better than me.
You are created the symbolic link to the wrong file. As far as I know virtualenv is installed to /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv, (you can change the numbers for your Python version) so the command for creating the symbolic link should be:
ln -s /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv /usr/local/bin/virtualenv
I'm trying to create a virtualenv with virtualenvwrapper, but when I use mkvirtualenv I get the following :
ERROR: virtualenvwrapper could not find virtualenv in your path
I assumed it was a PYTHONPATH problem.
But if I do a pip show virtualenv I get the following :
---
Metadata-Version: 2.0
Name: virtualenv
Version: 13.1.0
Summary: Virtual Python Environment builder
Home-page: https://virtualenv.pypa.io/
Author: Jannis Leidel, Carl Meyer and Brian Rosner
Author-email: python-virtualenv#groups.google.com
License: MIT
Location: /Volumes/Data/nfs/zfs-student-3/users/2013_paris/vmonteco/Library/Python/2.7/lib/python/site-packages
Requires:
And here is my PYTHONPATH :
/nfs/zfs-student-3/users/2013_paris/vmonteco/Library/Python/2.7/bin:/nfs/zfs-student-3/users/2013_paris/vmonteco/Library/Python/2.7/bin:/nfs/zfs-student-3/users/2013_paris/vmonteco/Library/Python/2.7/lib/python/site-packages:/Volumes/Data/nfs/zfs-student-3/users/2013_paris/vmonteco/Library/Python/2.7/lib/python/site-packages:~/.brew/Cellar
It contains the directory containing virtualenv!
(i-e : /Volumes/Data/nfs/zfs-student-3/users/2013_paris/vmonteco/Library/Python/2.7/lib/python/site-packages )
My ~/.zshrc contains :
export WORKON_HOME=~/Envs
export PROJECT_HOME=$HOME/Devel
source $HOME"/Library/Python/2.7/bin/virtualenvwrapper.sh"
EDIT :
virtualenvwrapper.sh is written in bash, perhaps should I check my PATH instead of my PYTHONPATH ?
So, what could the problem be? How could I fix it?
Thank you in advance for your help.
Re-installling virtualenv fixed my problem.
I had the same issue.
$ mkvirtualenv mysite
ERROR: virtualenvwrapper could not find virtualenv in your path
After a lot of time consuming efforts,
I decided to re-install virtualenv.
sudo apt install virtualenv
This fixed my issues.
I already had virtualenv installed. But I think it got broken or met with some errors.
I am using python3 with virtualenvwrapper installed on Ubuntu 18.04, using pip3 without sudo. If you are in this situation, you might find interesting my configuration.
In the end of my .bashrc I added the following rows (remember to put your username in the YOUR_USERNAME field):
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVWRAPPER_VIRTUALENV=/home/YOUR_USERNAME/.local/bin/virtualenv
source /usr/local/bin/virtualenvwrapper.sh
Then restart the cli with ctrl-D ctrl-T or reload the config with source ~/.bashrc.
Then you should be good to go! Try the installation with:
lsvirtualenv
mkvirtualenv test
workon test
deactivate
rmvirtualenv test
If you could create and delete a virtual environment, you are ready to go.
sudo find / -name "virtualenv"
Then I find the executable file path is:
/usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/bin/virtualenv
Touch a soft link in the /usr/local/bin/ directory or add the path to .bash_profile, I prefer the former:
sudo ln -s /usr/local/Cellar/python/2.7.12/Frameworks/Python.framework/Versions/2.7/bin/virtualenv /usr/local/bin/virtualenv
I finally found out what the problem was :
virtualenvwrapper.sh is written in BASH and not in Python.
So virtualenv is called from a shell (zsh).
I didn't have to bother about my PYTHONPATH, but about my PATH (I was already able to import virtualenv from my python shell anyway).
I just added the correct directory to my PATH and everything worked fine (the directory containing the virtualenv executable, i-e /Volumes/Data/nfs/zfs-student-3/users/2013_paris/vmonteco/Library/Python/2.7/lib/python/site-packages which isn't included in my PATH by default despite being the directory virtualenv and other pip-installed tools was in).
Find where is your virtualenvwrapper located. in my case
~/.local/bin
May be it's installed in
/usr/local/bin/
It totally depends on the System or Package Manager you are using.
Add this path in your shell configuration .bashrc or .zshrc or whatever by simply
PATH=$PATH:<directory_you_want_to_add>
for example
PATH=$PATH:~/.local/bin
Also add the following configuration in .bashrc or .zshrc
# the path you want your virtual environments to be saved and loaded from
export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/<project_folder>
# most important, this is the program which loads virtualenv
# please update the path where virtualenvwrapper.sh is located
source /usr/local/bin/virtualenvwrapper.sh
Don't Forget to restart the shell.. or reload the configuration...
To test whether it worked
mkvirtualenv test
if you see a test environment created then everything is ok.
For Detailed Installation Instructions go to the docs: virtualenvwrapper installation
For me it was:
export PYTHONPATH=/usr/bin/python3
export PATH=$HOME/.local/bin:$PATH
export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/Devel
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/local/bin/virtualenv
source ~/.local/bin/virtualenvwrapper.sh
I changed the line to:
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/bin/virtualenv
It worked.
ERROR: virtualenvwrapper could not find virtualenv in your path
This error means - program virtualenv is not in your system path. This mostly happens if you install virtualenv via pip without sudo. This kind of installation stores data in users local directory e.g ~/.local/bin. So first step is to find where this binary present. You can do that using locate program. First update its database using sudo updatedb. Then run locate *bin/virtualenv. Whatever path you get, append it in system path variable. This you can do by adding below line in your shell config file e.g. ~/.bashrc or ~/.zshenv.
export PATH=$PATH:/your/path
e.g.
export PATH=$PATH:~/.local/bin
Now open new shell and try again. Error should be gone.
In my case, I tested use this command:
sudo find / -name "virtualenv"
and I have a list with all path to this file,
I tested one to one and solved with path:
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/bin/virtualenv
My configurations to environment variables is :
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
export WORKON_HOME=$HOME/.virtualenv
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/bin/virtualenv
source ~/.local/bin/virtualenvwrapper.sh
in file .bashrc.
Now all its works.
The way I did it was (using zsh) in this way:
export PATH=$HOME/bin:/usr/local/bin:$PATH:/Users/username/Library/Python/2.7/bin:$PATH
I simply located the file of virtualenvwrapper.sh inside this path /Users/username/Library/Python/2.7/bin:$PATH
and added that path to PATH.
I have set the variable VIRTUALENVWRAPPER_VIRTUALENV in my .zshrc to the full path of the virtualenv binary and it works for me.
Here is my .zshrc file:
export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/Devel
export VIRTUALENVWRAPPER_VIRTUALENV=$HOME/Library/Python/2.7/bin/virtualenv
source $HOME/Library/Python/2.7/bin/virtualenvwrapper.sh
Your PYTHONPATH makes me think you have Homebrew installed. It sounds like virtualenvwrapper was installed with either your system pip or your homebrew pip while it is being executed with the opposite python interpreter.
I had this same issues and tried many many things, what found as a solution is i had three pip version, pip with 2.7, 3.6 and 3.7. and 3.6 was the one works fine for many things, and install as sudo pip3.6 install virtualenv, and it works fine.
I would suggest, check your pip version and tried to install based on your pip ver.
Removing all virtualenv related packages would work.
pip freeze -l | grep ^virtualenv | awk -F= '{print $1}' | xargs pip uninstall -y
Using pip3 to install a package in a virtualenv causes the package to be installed in the global site-packages folder instead of the one in the virtualenv folder. Here's how I set up Python3 and virtualenv on OS X Mavericks (10.9.1):
I installed Python3 using Homebrew:
ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl
Changed the $PATH variable in .bash_profile; added the following line:
export PATH=/usr/local/bin:$PATH
Running which python3 returns /usr/local/bin/python3 (after restarting the shell).
Note: which python3 still returns /usr/bin/python though.
Installed virtualenv using pip3:
pip3 install virtualenv
Next, create a new virtualenv and activate it:
virtualenv testpy3 -p python3
cd testpy3
source bin/activate
Note: if I don't specify -p python3, pip will be missing from the bin folder in the virtualenv.
Running which pip and which pip3 both return the virtualenv folder:
/Users/kristof/VirtualEnvs/testpy3/bin/pip3
Now, when I try to install e.g. Markdown using pip in the activated virtualenv, pip will install in the global site-packages folder instead of the site-packages folder of the virtualenv.
pip install markdown
Running pip list returns:
Markdown (2.3.1)
pip (1.4.1)
setuptools (2.0.1)
virtualenv (1.11)
Contents of /Users/kristof/VirtualEnvs/testpy3/lib/python3.3/site-packages:
__pycache__/
_markerlib/
easy_install.py
pip/
pip-1.5.dist-info/
pkg_resources.py
setuptools/
setuptools-2.0.2.dist-info/
Contents of /usr/local/lib/python3.3/site-packages:
Markdown-2.3.1-py3.3.egg-info/
__pycache__/
easy-install.pth
markdown/
pip-1.4.1-py3.3.egg/
setuptools-2.0.1-py3.3.egg
setuptools.pth
virtualenv-1.11-py3.3.egg-info/
virtualenv.py
virtualenv_support/
As you can see, the global site-packages folder contains Markdown, the virtualenv folder doesn't.
Note: I had Python2 and Python3 installed before on a different VM (followed these instructions) and had the same issue with Python3; installing packages in a Python2 based virtualenv worked flawlessly though.
Any tips, hints, … would be very much appreciated.
Funny you brought this up, I just had the exact same problem. I solved it eventually, but I'm still unsure as to what caused it.
Try checking your bin/pip and bin/activate scripts. In bin/pip, look at the shebang. Is it correct? If not, correct it. Then on line ~42 in your bin/activate, check to see if your virtualenv path is right. It'll look something like this
VIRTUAL_ENV="/Users/me/path/to/virtual/environment"
If it's wrong, correct it, deactivate, then . bin/activate, and if our mutual problem had the same cause, it should work. If it still doesn't, you're on the right track, anyway. I went through the same problem solving routine as you did, which piping over and over, following the stack trace, etc.
Make absolutely sure that
/Users/kristof/VirtualEnvs/testpy3/bin/pip3
is what you want, and not referring to another similarly-named test project (I had that problem, and have no idea how it started. My suspicion is running multiple virtualenvs at the same time).
If none of this works, a temporary solution may be to, as Joe Holloway said,
Just run the virtualenv's pip with its full path (i.e. don't rely on searching the executable path) and you don't even need to activate the environment. It will do the right thing.
Perhaps not ideal, but it ought to work in a pinch.
Link to my original question:
VirtualEnv/Pip trying to install packages globally
For me this was not a pip or virtualenv problem. It was a python problem. I had set my $PYTHONPATH manually in ~/.bash_profile (or ~/.bashrc) after following some tutorial online. This manually set $PYTHONPATH was available in the virtualenv as it probably should be allowed.
Additionally add2virtualenv was not adding my project path to my $PYTHONPATH for some reason within the virtualenv.
Just some forking paths for those who might still be stuck! Cheers!
I had the same problem, I solved it by removing venv directory and recreating it!
deactivate (if venv is activated first deactivate it)
rm -rf venv
virtualenv -p python3 venv
. ENV/bin/activate
pip3 install -r requirements.txt
Now everything works like a charm.
Edit: Here's the above code modified for Python3's venv:
deactivate # (if venv is activated first deactivate it)
rm -rf venv # Delete the old venv directory
python3 -m venv venv # Recreate a new, empty venv
. venv/bin/activate # Activate it
pip3 install -r requirements.txt # Install the dependencies
The first thing to check is which location pip is resolving to:
which pip
if you are in a virtualenv you would expect this to give you something like:
/path/to/virtualenv/.name_of_virtualenv/bin/pip
However it may be the case that it's resolving to your system pip for some reason. For example you may see this from within your virtualenv (this is bad):
/usr/local/bin/pip
(or anything that isn't in your virtualenv path).
To solve this check your pipconfig in:
~/.pipconf
~/.conf/pip
/etc/pip.conf
and make sure that there is nothing that is coercing your Python path or your pip path (this fixed it for me).
Then try starting a new terminal and rebuild your virtualenv (delete then create it again)
I had the same issue on macos with python 2 and 3 installed.
Also, I had aliases to point to python3 and pip3 in my .bash_profile.
alias python=/usr/local/bin/python3
alias pip=/usr/local/bin/pip3
Removing aliases and recreating virtual env using python3 -m venv venv fixed the issue.
Go to bin directory in your virtual environment and write like this:
./pip3 install <package-name>
I had this problem too. Calling pip install <package_name> from the /bin directory within my Python 3.3 virtual environment on my Mavericks Mac caused the Python package to be installed in the Python 2.7 global site packages directory. This was despite the fact that my $PATH started with the directory containing pip. Weird. This doesn't happen on CentOS. For me, the solution was calling pip3 instead of pip. When I had installed pip within the virtual environment via ez_setup, three "pip" executables had been installed in the /bin directory - pip, pip3, and pip3.3. Curiously, all three files were exactly the same. Calling pip3 install <package_name> caused the Python package to be installed correctly into the local site-packages directory. Calling pip with the full pathname into the virtual environment also worked correctly. I'd be interested to know why my Mac isn't using $PATH the way I would expect it to.
I hit into the same issue while installing a python package from within a virtualenv.
The root cause in my case was different.
From within the virtualenv, I was (out of habit on Ubuntu), doing:
sudo easy_install -Z <package>
This caused the bin/pip shebang to be ignored and it used the root's non virtualenv python to install it in the global site-packages.
Since we have a virtual environment, we should install the package without "sudo"
I stumbled upon the same problem running Manjaro. I created the virtual environment using python3 -m ven venv and then activated using source venv/bin/actiave. which python and which pip both pointed towards the correct binaries in the virtualenv, however I was not able to install to the virtualenv, even when using the full path of the binaries. Turned out that when I uninstalled the python-pip package with sudo pacman -R python-pip python-reportlab (had to include reportlab to satisfy dependencies) everything started to work as expected. Not sure why, but this is probably due to a double install where the system package is taking precedence.
I had a similar problem after updating to pip==8.0.0. Had to resort to debugging pip to trace out the bad path.
As it turns out my profile directory had a distutils configuration file with some empty path values. This was causing all packages to be installed to the same root directory instead of the appropriate virtual environment (in my case /lib/site-packages).
I'm unsure how the config file got there or how it had empty values but it started after updating pip.
In case anyone else stumbles upon this same problem, simply deleting the file ~/.pydistutils.cfg (or removing the empty config path) fixed the problem in my environment because pip went back to the default distributed configuration.
Here are some practices that could avoid headaches when using Virtual Environments:
Create a folder for your projects.
Create your Virtualenv projects inside of this folder.
After activating the environment of your project, never use "sudo pip install package".
After finishing your work, always "deactivate" your environment.
Avoid renaming your project folder.
For a better representation of this practices, here is a simulation:
creating a folder for your projects/environments
$ mkdir venv
creating environment
$ cd venv/
$ virtualenv google_drive
New python executable in google_drive/bin/python
Installing setuptools, pip...done.
activating environment
$ source google_drive/bin/activate
installing packages
(google_drive) $ pip install PyDrive
Downloading/unpacking PyDrive
Downloading PyDrive-1.3.1-py2-none-any.whl
...
...
...
Successfully installed PyDrive PyYAML google-api-python-client oauth2client six uritemplate httplib2 pyasn1 rsa pyasn1-modules
Cleaning up...
package available inside the environment
(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:30:19)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
>>>
>>> gdrive = pydrive.auth.GoogleAuth()
>>>
deactivate environment
(google_drive) $ deactivate
$
package NOT AVAILABLE outside the environment
(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:32:10)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named pydrive.auth
>>>
Notes:
Why not sudo?
Virtualenv creates a whole new environment for you, defining $PATH and some other variables and settings. When you use sudo pip install package, you are running Virtualenv as root, escaping the whole environment which was created, and then, installing the package on global site-packages, and not inside the project folder where you have a Virtual Environment, although you have activated the environment.
If you rename the folder of your project (as mentioned in the accepted answer)...
...you'll have to adjust some variables from some files inside the bin directory of your project.
For example:
bin/pip, line 1 (She Bang)
bin/activate, line 42 (VIRTUAL_ENV)
Came across the same issue today. I simply reinstalled pip globally with sudo easy_install pip (OSX/ Max), then created my virtualenv again with sudo virtualenv nameOfVEnv. Then after activating the new virtualenv the pip command worked as expected.
I don't think I used sudo on the first virtualenv creation and that may have been the reason for not having access to pip from within the virtualenv, I was able to get access to pip2 before this fix though which was odd.
I had this problem. It turned out there was a space in one of my folder names that caused the problem. I removed the space, deleted and reinstantiated using venv, and all was well.
This problem occurs when create a virtualenv instance and then change the parent folder name.
None of the above solutions worked for me.
My venv was active.
pip -V and which pip gave me the correct virtualenv path, but when I pip install-ed packages with activated venv, my pip freeze stayed empty.
All the environment variables were correct too.
Finally, I just changed pip and removed virtualenv:
easy_install pip==7.0.2
pip install pip==10
sudo pip uninstall virtualenv
Reinstall venv:
sudo pip install virtualenv
Create venv:
python -m virtualenv venv_name_here
And all packages installed correctly into my venv again.
After creating virtual environment, try to use pip located in yourVirtualEnvName\Scripts
It should install a package inside Lib\site-packages in your virtual environment
I had a similar problem on Windows. It was caused by renaming folder structures in my project within a virtualenv folder name. The paths in files didn't change but stayed as they were when virtual env was created. As Chase Ries mentioned I've changed the paths to VIRTUAL_ENV and python.exe in files
./venv/Scripts/activate.bat, set "VIRTUAL_ENV=path_to_venv\venv" 11 line in file
./venv/Scripts/Activate.ps1, $env:VIRTUAL_ENV="path_to_venv\venv" 30 line in file
./venv/Scripts/pip.exe, #!d:\path_to_env\venv\scripts\python.exe this line is at the end of a file, in my case moved to the right in 667 line, I am working on disc d so at the begining of the path is the letter of it
./venv/Scripts/pip3.7.exe, #!d:\path_to_env\venv\scripts\python.exe this line is at the end of a file, in my case moved to the right in 667 line
./venv/Scripts/pip3.exe, #!d:\path_to_env\venv\scripts\python.exe this line is at the end of a file, in my case moved to the right in 667 line
I had this problem too. Calling sudo pip install caused Python packages to be installed in the global site-packages diretory and calling pip install just worked fine.
So no use sudo in virtualenv.
The same problem. Python3.5 and pip 8.0.2 installed from Linux rpm's.
I did not find a primary cause and cannot give a proper answer. It looks like there are multiple possible causes.
However, I hope I can help with sharing my observation and a workaround.
pyvenv with --system-site-packages
./bin does not contain pip, pip is available from system site packages
packages are installed globally (BUG?)
pyvenv without --system-site-packages
pip gets installed into ./bin, but it's a different version (from ensurepip)
packages are installed within the virtual environment (OK)
Obvious workaround for pyvenv with --system-site-packages:
create it without the --system-site-packages option
change include-system-site-packages = false to true in pyvenv.cfg file
It's also worth checking that you didn't modify somehow the path to your virtualenv.
In that case the first line in bin/pip (and the rest of the executables) would have an incorrect path.
You can either edit these files and fix the path or remove and install again the virtualenv.
For Python 3ers
Try updating. I had this exact same problem and tried Chases' answer, however no success. The quickest way to refactor this is to update your Python Minor / Patch version if possible. I noticed that I was running 3.5.1 and updated to 3.5.2. Pyvenv once again works.
This happened to me when I created the virtualenv in the wrong location. I then thought I could move the dir to another location without it mattering. It mattered.
mkdir ~/projects
virtualenv myenv
cd myenv
git clone [my repository]
Oh crap, I forgot to cd into projects before creating the virtualenv and cloning the rep. Oh well, I'm too lazy to destroy and recreate. I'll just move the dir with no issues.
cd ~
mv myenv projects
cd projects/myenv/myrepo
pip install -r requirements
Nope, wants more permissions, what the?
I thought it was strange but SUDO AWAY! It then installed the packages into a global location.
The lesson I learned was, just delete the virtualenv dir. Don't move it.
Had this issue after installing Divio: it had changed my PATH or environment in some way, as it launches a terminal.
The solution in this case was just to do source ~/.bash_profile which should already be setup to get you back to your original pyenv/pyenv-virtualenv state.
Somehow a setup.cfg file with a prefix="" in the project folder
running pip install on the virtualenv outside the project folder worked so from the inside it was telling pip to use an empty prefix which defaults to "/"
removing the file fixed it
I had this problem, and after trying all the above solution I just removed everything and started afresh.
In my own case i used sudo in creating one of the folders in which the virtual environment existed, and sudo give the priviledges to root
I was very pissed! But it worked!
I have to use 'sudo' for installing packages through pip on my ubuntu system for some reason. This is causing the packages to be installed in global site-packages. Putting this here for anyone who might face this issue in future.
I had exactly the problem from the title, and I solved it. Pip started to install in the venv site-packages after I cleaned my PATH: it had a path to my local ~/bin directory at the very beginning.
So, my advice: thoroughly check your environment variables for "garbage" or any non-standard things. Unfortunately, virtualenv can be sensitive to those.
Good luck!
Short answer is run Command virtualenv with parameter “—no-site-packages”.
Long answer with explanation :-
So after running here and there, and going through lot of threads i found my self the problem. Above answers have given the idea but I would like to go again over everything though.
The problem is even if you’re activating the environment it’s referring to the system environment because of the way we have crated the virtualenv.
when we run the command virtualenv env -p python3
it will install the virtualenv but it will not create no-global—site-packages.txt.
Because of that when you activate the environment by source activate command there this file called site.py (name can be different, i just forgot ) which runs and checks if this file is not present it will not add your env path to sys.path and use systems python.
to fix this issue just run virtualenv with extra parameter —no-site-packages it will create that file and when you activate the environment it will add your custom environment path in your PATH variable making it accessible.
Lot of good discussion above, but virtualenv examples were used. Since 'conda' is now the recommended tool to manage virtualenv, I have summarized the steps in running pip in conda env as follow.
I'll use py36r as the name of the env, and /opt/conda/envs is the prefix to the envs):
$ source /opt/conda/etc/profile.d/conda.sh # skip if already done
$ conda activate py36r
$ pip install pkg_xyz
$ pip list | grep pkg_xyz
Note that the pip executed should be in /opt/conda/envs/py36r/bin/pip (not /opt/conda/bin/pip).
Alternatively, you can simply run the following without conda activate
$ /opt/conda/envs/py36r/bin/pip
Also, if you install using conda, you can install without activate:
$ conda install -n py36r pkg_abc ...
WINDOWS
For me solution was not to use
mkvirtualenv, but:
python -m venv path/to/your/virtualenv
workon works correctly.
while in virtualenv: pip -V shows virtualenv's path to pip
In attempting to get started learning and developing python, I've tried to follow the Python Guide to installing python on OS X, but haven't found it particularly "noob friendly." I have a new MacBook (Mtn. Lion - OS X 10.8.3) wich comes with Python 2.7.2 built in. But the guide advises installing a "framework-style build" via homebrew. So:
I installed homebrew via ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
Then it tells you to add homebrew to the top of your PATH by adding it to your ~/.bashrc file. ls -a showed that I did not have a ~/.bashrc file in my home directory. After searching Stack Overflow on how to do that, I ran nano ~/.bashrc, and inserted the line export PATH=/usr/local/bin:$PATH to the file and saved the file.
I then ran brew install python --framework and the install completed.
Then, the guide says to "add the new Python scripts directory to your PATH" so, I'm assuming that means I need to add the line it provides to my ~/.bashrc file also. So, I added export PATH=/usr/local/share/python:$PATH to my ~/.bashrc file above my previous entry.
Finally, this is where I run into trouble, it says to easy_install pip. However, when I do that I get an error 13.
So, here are the things I need some help with.
Was I correct in my assumptions about how to add homebrew and python scripts to my PATH?
Did I do something wrong or do I just need to use sudo to install pip? (I'm really sorry if the answer is already on this page but even those answers don't make total sense to me and I want to be careful and not screw something up)
After installing the framework-style build of python (which I believe was the current 2.7.3), how come running python in my terminal still shows v2.7.2?
Thanks! I appreciate any help.
I've tried to follow the Python Guide to installing python on OS X,
but haven't found it particularly "noob friendly.
Yes, I think it is misleading/outdated.
Then it tells you to add homebrew to the top of your PATH by adding it
to your ~/.bashrc file. ls -a showed that I did not have a ~/.bashrc
file in my home directory. After searching Stack Overflow on how to do
that, I ran nano ~/.bashrc, and inserted the line export
PATH=/usr/local/bin:$PATH to the file and saved the file.
On the Mac, just use ~/.profile
I then ran brew install python --framework and the install completed.
I think you don't need the --framework option unless you want to replace your Mac OS default installation and need an Mac OS Framework-style directory layout. There is no need to replace it though, the homebrew installation will take precedence anyway.
Then, the guide says to "add the new Python scripts directory to your
PATH" so, I'm assuming that means I need to add the line it provides
to my ~/.bashrc file also. So, I added export
PATH=/usr/local/share/python:$PATH to my ~/.bashrc file above my
previous entry.
Again, do it in ~/.profile. And don't forget to do a
source ~/.profile
otherwise the changes will only become active in any new terminal window, not the one you are currently using.
Finally, this is where I run into trouble, it says to easy_install
pip. However, when I do that I get an error 13.
The error shows that you try to install it your Mac OS system's default Python library (rather than in /usr/local, homebrew style), which would require root privileges. Just don't.
Also, with homebrew python, pip is already installed.
Check your path:
$ which pip
/usr/local/bin/pip
$ ls -l /usr/local/bin/pip
[..] /usr/local/bin/pip -> ../Cellar/python/2.7.3/bin/pip
Added bonus: Then do
pip install virtualenv
and use that.
And to your questions:
Was I correct in my assumptions about how to add homebrew and python
scripts to my PATH?
Yes, but use .profile and do a source .profile afterwards.
Did I do something wrong or do I just need to use sudo to install pip?
(I'm really sorry if the answer is already on this page but even those
answers don't make total sense to me and I want to be careful and not
screw something up)
You don't need sudo with homebrew, and pip is installed automatically with homebrew python.
After installing the framework-style build of python (which I believe
was the current 2.7.3), how come running python in my terminal still
shows v2.7.2?
Probably PATH not correct, do echo $PATH and check that it is correct. That is unrelated to being "framework-style" or not, though.
If you installed python with homebrew, you should already have pip installed. Try running
pip --version
to see whether and where pip is installed. Hopefully it's in a /usr/local/... path where your other homebrew things live.
Also before you install too much more with homebrew be sure to run these commands:
brew update
brew doctor
Good luck!
I've installed virtualenv via pip and get this error after creating a new environment:
selenium:~ auser$ virtualenv new
New python executable in new/bin/python
ERROR: The executable new/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/System/Library/Frameworks/Python.framework/ Versions/2.6' (should be '/Users/user/new')
ERROR: virtualenv is not compatible with this system or executable
In my environment:
PYTHONPATH=/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
PATH=/System/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
How can I repair this?
Thanks.
Just in case there's someone still seeking for the answer.
I ran into this same problem just today and realized since I already have Anaconda installed, I should not have used pip install virtualenv to install virtual environment as this would give me the error message when trying to initiate it later. Instead, I tried conda install virtualenv then entered virtualenv env_mysite and problem solved.
Like #RyanWilcox mentioned, you might be inadvertently pointing virtualenv to the wrong Python installation. Virtualenv comes with a -p flag to let you specify which interpreter to use.
In my case,
virtualenv test_env
threw the same error as yours, while
virtualenv -p python test_env
worked perfectly.
If you call virtualenv -h, the documentation for the -p flag will tell you which python it thinks it should be using; if it looks wonky, try passing -p python. For reference, I'm on virtualenv 1.11.6.
In case anyone in the future runs into this problem - this is caused by your default Python distribution being conda. Conda has it's own virtual env set up process but if you have the conda distribution of python and still wish to use virtualenv here's how:
Find the other python distribution on your machine: ls -ls /usr/bin/python*
Take note of the availble python version that is not conda and run the code below (note for python 3 and above you have to upgrade virtualenv first): virtualenv -p python2.7(or your python version) flaskapp
I've run across this problem myself. I wrote down the instructions in a README, which I have pasted below....
I have found there are two things that work:
Make sure you're running the latest virtualenv (1.5.1, of this writting)
If you're using a non system Python as your standard Python (which python to check) Forcefully use the System supplied one.
Instead of virtualenv thing use /usr/bin/python2.6 PATH/TO/VIRTUALENV thing (or whatever which
python returned to you - this is what it did for me when I ran into this issue)
I had the same problem and as I see it now, it was caused by a messy Python installation. I have OS X installed for over a year since I bought a new laptop and I have already installed and reinstalled Python for several times using different sources (official binaries, homebrew, official binaries + hand-made adjustments as described here). Don't ask me why I did that, I'm just a miserable newbie believing everything will fix itself after being re-installed.
So, I had a number of different Pythons installed here and there as well as many hardlinks pointing at them inconsistently. Eventually I got sick of all of them and reinstalled OS X carefully cleaned the system from all the Pythons I found using find utility. Also, I have unlinked all the links pointing to whatever Python from everywhere. Then I've installed a fresh Python using homebrew, installed virtualenv and everything works as a charm now.
So, my recipe is:
sudo find / -iname "python*" > python.log
Then analyze this file, remove and unlink everything related to the version of Python you need, reinstall it (I did it with homebrew, maybe official installation will also work) and enjoy. Make sure you unlink everything python-related from /usr/bin and /usr/local/bin as well as remove all the instances of Frameworks/Python.framework/Versions/<Your.Version> in /Library and /System/Library.
It may be a dirty hack, but it worked for me. I prefer not to keep any system-wide Python libraries except pip and virtualenv and create virtual environments for all of my projects, so I do not care about removing the important libraries. If you don't want to remove everything, still try to understand whether your Pythons are, what links point to them and from where. Then think what may cause the problem and fix it.
I ran into a variation of this "not functioning" error.
I was trying to create an environment in a folder that included the path ".../Programming/Developing..." which is actually "/Users/eric/Documents/Programming:Developing/"
and got this error:
ImportError: No module named site
ERROR: The executable env/bin/python2.7 is not functioning
ERROR: It thinks sys.prefix is u'/Users/eric/Documents/Programming:Developing/heroku' (should be u'/Users/eric/Documents/Programming:Developing/heroku/env')
ERROR: virtualenv is not compatible with this system or executable
I tried the same in a different folder and it worked fine, no errors and env/bin has what I expect (activate, etc.).
I got the same problem and I found that it happens when you do not specify the python executable name properly. So for python 2x, for example:
virtualenv --system-site-packages -p python mysite
But for python 3.6 you need to specify the executable name like python3.6
virtualenv --system-site-packages -p python3.6 mysite
On on OSX 10.6.8 leopard, after having "upgraded" to Lion, then downgrading again (ouch - AVOID!), I went through the Wolf Paulus method a few months ago, completely ignorant of python. Deleted python 2.7 altogether and "replaced" it with 3.something. My FTP program stopped working (Fetch) and who knows what else relies on Python 2.7. So at that point I downloaded the latest version of 2.7 from python.org and it's installer got me up and running - until i tried to use virtualenv.
What seems to have worked for me this time was totally deleting Python 2.7 with this code:
sudo rm -R /System/Library/Frameworks/Python.framework/Versions/2.7
removing all the links with this code:
sudo rm /usr/bin/pydoc
sudo rm /usr/bin/python
sudo rm /usr/bin/pythonw
sudo rm /usr/bin/python-config
I had tried to install python with homebrew, but apparently it will not work unless all of XTools is installed, which I have been avoiding, since the version of XTools compatible with 10.6 is ancient and 4GB and mostly all I need is GCC, the compiler, which you can get here.
So I just installed with the latest download from python.org.
Then had to reinstall easy_install, pip, virtualenv.
Definitely wondering when it will be time for a new laptop, but there's a lot to be said for buying fewer pieces of hardware (slave labor, unethical mining, etc).
The above solutions failed for me, but the following worked:
python3 -m venv --without-pip <ENVIRONMENT_NAME>
. <ENVIRONMENT_NAME>/bin/activate
curl https://bootstrap.pypa.io/get-pip.py | python
deactivate
It's hacky, but yes, the core problem really did just seem to be pip.
I did the following steps to get virtualenv working :
Update virtualenv as follows :
==> sudo pip install --upgrade virtualenv
Initialize python3 virtualenv :
==> virtualenv -p python3 venv
I had this same issue, and I can confirm that the problem was with an outdated virtualenv.py file.
It was not necessary to do a whole install --upgrade.
Replacing the virtualenv.py file with the most recent version sufficed.
I also had this problem, and I tried the following method which worked for me:
conda install virtualenv
virtualenv --system-site-packages /anaconda/envs/tensorflow (here envs keeps all the virtual environments made by user)
source /anaconda/envs/tensorflow/bin/activate
Hope it's helpful.
I had this same issue when trying to install py2.7 on a newer system. The root issue was that virtualenv was part of py3.7 and thus was not compatible:
$ virtualenv -p python2.7 env
Running virtualenv with interpreter /usr/local/bin/python2.7
New python executable in /Users/blah/env/bin/python
ERROR: The executable /Users/blah/env/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/Library/Frameworks/Python.framework/Versions/2.7' (should be u'/Users/blah/env')
ERROR: virtualenv is not compatible with this system or executable
$ which virtualenv
/Library/Frameworks/Python.framework/Versions/3.7/bin/virtualenv
# install proper version of virtualenv
$ pip2.7 install virtualenv
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv -p python2.7 env
$ . ./env/bin/activate
(env) $
Open terminal and type /Library/Frameworks/Python.framework/Versions/
then type ls /Library/Frameworks/Python.framework/Versions/2.7/bin/
if you are using Python2(or any other else).
Edit ~/.bash_profile and add the following line:
export PATH=$PATH:/Library/Frameworks/Python.framework/Versions/2.7/bin/
cat ~/.bash_profile
In my case the content of ~/.bash_profile is as follows:
export PATH=$PATH:/Library/Frameworks/Python.framework/Versions/2.7/bin/
Now the virtualenv command should work.
If you continue to have trouble with virtualenv, you might try pythonbrew, instead. It's an alternate solution to the same problem. It works more like Ruby's rvm: It builds and creates an entire instance of Python, under $HOME/.pythonbrew, and then sets up some bash functions that allow you to switch easily between versions. Where virtualenv shadows the system version of Python, using symbolic links as part of its solution, pythonbrew builds entirely self-contained installations of Python.
I used virtualenv for years. It's a decent solution, but I've switched to pythonbrew lately. Having completely self-contained Python instances means that installing a new one takes awhile (since pythonbrew actually compiles Python from scratch), but the self-contained nature of each installation appeals to me. And disk is cheap.