We Keep Coding

Virtualenv installing a package in the global directory

I made sure to read this question and similar ones, but I couldn't find an answer to my problems.
My problem is: when I head into muy virtual env and activate it, if I install a package there, it is also installed elsewhere in my computer.
So, for example, if I type in the terminal:
cd home/Documents/Python/tests/my_virtual_env
source bin/activate
That activates the virtual environment. If I type:
pip3 install wget #just an example package
I see the installation process and I can run a .py script that uses wget. However, why is this package also installed elsewhere in my computer?
I made sure I hadn't that package installed beforehand using pip3 list.
I confirmed that package was installed elsewhere by running a .py script from other directories (using cd /etc.etc/ to change directory and then running it from there).
I deactivated the environment in the right moment.
I also realized that if I uninstall that package within the virtualenv, it is also uninstalled elsewhere.
Thank you so much for your help.

It could be that the pip3 command being executed is not actually tied to the virtual environment. So instead you could the following, which would work whether or not the virtual environment is activated:
$ path/to/my_virtual_env/bin/python3 -m pip install SomeProject
The following command should give you a relatively clear indication of where exactly the project has been installed, make sure it is in the site-packages directory of the virtual environment:
$ path/to/my_virtual_env/bin/python3 -m pip show SomeProject
So it should show something of the sort:
Name: SomeProject
...
Location: .../path/to/my_virtual_env/lib.python3.X/site-packages
However, why is this package also installed elsewhere in my computer?
The following shows where a binary is located:
$ which somecommand
It should be relatively easy to recognize if somecommand is in a Python virtual environment or not.

"virtualenv is not compatible with this system or executable" using virtual env and anaconda

I'm trying to start up a virtual env using virtualenv, am getting this error:
Already using interpreter /Users/pkilcrease/anaconda/bin/python3
Using base prefix '/Users/pkilcrease/anaconda'
New python executable in /Users/pkilcrease/.virtualenvs/bodega/bin/python3
Also creating executable in /Users/pkilcrease/.virtualenvs/bodega/bin/python
ERROR: The executable /Users/pkilcrease/.virtualenvs/bodega/bin/python3 is not functioning
ERROR: It thinks sys.prefix is '/Users/pkilcrease/.virtualenvs' (should be '/Users/pkilcrease/.virtualenvs/bodega')
ERROR: virtualenv is not compatible with this system or executable
The command I am running is mkvirtualenv -a . --no-site-packages --python='which python3' -r requirements.txt bodega
My .bashrc file currently looks like this:
export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVWRAPPER_SCRIPT=/Users/pkilcrease/anaconda/bin/virtualenvwrapper.sh
source /Users/pkilcrease/anaconda/bin/virtualenvwrapper_lazy.sh
I have the feeling that there is some issue with anaconda and virtualenv which is causing the problem here, but not sure how to remedy that or if it's just a red herring.

If using a conda python executable, use conda create --name {your_venv} python=3 (note there is a virtualenv utility that comes with conda, but still use conda create... to make new virtual env's).
Otherwise, when using a version of python installed by the system package manager, create a virtual env using virtualenv, or preferably using the virtualenvwrapper utility mkvirtualenv. For example on Linux, the "system python" is /usr/bin/python3, /usr/bin/python, /usr/bin/python2, etc. Or, as it's clear you're on MacOS, that would likely be a python installed by brew (homebrew) or port (macports) in /opt or /usr/local. You may have to install virtualenvwrapper in order to get mkvirtualenv (and lsvirtualenv, etc).
In short, if you're using anaconda python, stick with conda utils. Else, if you're keeping your python free & open (as many of your corp IT data centers do), then use any of the various open utils like mkvirtualenv, etc.

Hopefully this may help people still looking at this question, but an easy fix:
conda install -y virtualenv

`mkvirtualenv` doesn't work after install anaconda Python

Before I installed anaconda, I usually start project with virtualenvwrapper :
mkvirtualenv --python=python3.5 myproject
workon pystagram myproject
where which python3.5 shows,
>> /usr/local/bin/python3.5
But, after I installed anaconda, system-based-python changed to ananconda versions. So, which python3.5 shows,
>> /Users/Chois/anaconda/bin/python3.5
So, mkvirtualenv occurs errors :
Running virtualenv with interpreter /Users/Chois/anaconda/bin/python3.5
Using base prefix '/Users/Chois/anaconda'
New python executable in /Users/Chois/.virtualenvs/chois_jupyter/bin/python3.5
Also creating executable in /Users/Chois/.virtualenvs/chois_jupyter/bin/python
ERROR: The executable /Users/Chois/.virtualenvs/chois_jupyter/bin/python3.5 is not functioning
ERROR: It thinks sys.prefix is '/Users/Chois/.virtualenvs' (should be '/Users/Chois/.virtualenvs/chois_jupyter')
ERROR: virtualenv is not compatible with this system or executable
I think the best way I can use both virtualenvwrapper and anaconda is to do something like installing anaconda in virtual environment but as I know it is impossible.
What should I do?
(I usually do django-project in virtual-environment and start to study jupyter now)

I had the same problem with my previous setup of virtualenv and virtualenvwrapper after installing Anaconda/iPython. The way I managed to get it to work is to activate only one at a time not both. The changes I made when I need virtualenv or virtualenvwrapper:
edit .bash_profile
nano ~/.bash_profile
comment out the following line
# export PATH="/Users/XXX/anaconda3/bin:$PATH"
Rename the anaconda folder to something else temporary. mv ~/anaconda3 ~/_anaconda3
Restart your terminal. virtualenv/virtualenvwrapper should be back again.
When you need anaconda back, revert the changes.

virtualenv does not include pip

I am trying to create a virtual environment using virtualenv on Mac OS X El Capitan. I have installed Python 2.7.11 with brew, which includes pip, wheel and setuptools by default.
Hovewer, when I try to install virtualenv following instructions in the documentation or from any other resource, I get several problems:
virtualenv executable is not placed in /usr/local/bin after pip makes its job, so I need to ln -s it by hand (it may indicate, that there is something wrong with installation on this step).
After I run virtualenv venv, it creates new environment, catches Python 2.7.11 from brew-installation, but: there is no pip inside bin folder. That means, that if I try which pip, having venv activated, it returns a global position of pip — /usr/local/bin/pip, not /path/to/venv/bin/pip.
As a consequence, installing packages inside venv uses global pip and installs them to a global sites-packages, not that inside venv, and it's quite the opposite of what environment should do.
Could you please suggest what may be wrong and how to fix it?
EDIT: The thing to mention is that I used to have other versions of Python installed on my computer, which I have recently deleted as it is described in this answer. Maybe it causes the issue, and some more thorough cleaning is needed.

Try removing or renaming the .pydistutils.cfg file in your home directory, e.g. by renaming with mv ~/.pydistutils.cfg ~/oldpydistutils.cfg
I'm putting a detailed answer here to help others, but the original credit goes to this answer. If you know what specifically in .pydistutils.cfg was causing the problem, let me know!
I was having the same issue: my virtual environments were created without a local copy of pip, although they had a local copy of python. This meant that using $ pip from within the virtual environment installed to the global package location, and was not visible to the environment's python.
How I diagnosed this on my machine:
I create a virtualenvironment with $ virtualenv env
Activated the virtual environment with $ source env/bin/activate
Checked python location: run (env)$ which python with output /Users/<username>/env/bin/python (as expected)
Checked pip location: run (env)$ which pip with output /usr/local/bin/pip (NOT expected)
To check where our packages are going, we can try to install a package in the virtual environment:
Try to install a package: (env)$ pip install HTTPServer which succeeds
Try to run the package: (env)$ python -m HTTPServer which fails with error /Users/emunsing/env/bin/python: No module named HTTPServer
To double-check, try to install again: (env)$ pip install HTTPServer which produces Requirement already satisfied (use --upgrade to upgrade): HTTPServer in /usr/local/lib/python2.7/site-packages
Double-checking, we see that there's no Pip in the environment's /bin folder:
$ ls env/bin
activate activate.fish python python2
activate.csh activate_this.py python-config python2.7
And so while the system finds the local python version, it can't find a local pip to use and traverses the $PATH. It ended up using pip from /usr/local/bin, leaving me unable to install packages locally to the virtual environment.
Here's what I tried:
- Reinstalling python brew uninstall python followed by brew upgrade and brew install python --build-from-source
- Installing pip using the get-pip.py command as described in the Pip documentation
Here's what I ruled out:
- I was not using sudo pip ... which caused similar problems in this other question and haven't done so at any time on this Python/pip install
- My virtual environment didn't show a local installation of pip, as was the case in these similar questions: This one for Windows, This one for Mac OS X.
Ultimately, I found that eliminating the ~/.pydistutils.cfg file fixed the problem, allowing for fresh virtual environments that had their own local pip. The contents of my ~/.pydistutils.cfg file were:
[global]
verbose=1
[install]
install-scripts=$HOME/bin
[easy_install]
install-scripts=$HOME/bin
Simply renaming the ~/.pydistutils.cfg file appears to fix the problem: it seems that although this file was created by the homebrew installation, some settings in this file may be incompatible with virtualenv. While removing this file hasn't had any bad effects on my system, you may need to use the --user flag when installing packages with pip to the global environment (e.g. $ pip install --user HTTPServer). Here are more details on .pydistutils.cfg if you want to work on tailoring it for your needs.

virtualenv executable is not placed in /usr/local/bin after pip makes its job, so I need to ln -s it by hand (it may indicate, that there is something wrong with installation on this step).
Don't do that. That will only hide the bug and not solve the problem. Here's a short guide how to debug this kind of issues:
Start with which -a python. The first path you see should be /usr/local/bin/python, if not check your PATH variable.
Next, check which -a pip. Again the first path should be /usr/local/bin/pip. If not, run python -m ensurepip and recheck.
Now install virtualenv using pip install virtualenv, after that check the output of which -a virtualenv. The first path should be /usr/local/bin/virtualenv, if not check the output of env |grep PYTHON for unexpected environment variables.
Finally check the output of virtualenv --version to make sure you have the latest version.

I had the issue when running virtualenv: "ImportError: No module named pip."
My solution was to downgrade virtualenv. I had 16.2.0.
pip uninstall virtualenv
pip install virtualenv==15.1.0

Just hit same issue on Linux. Seems like there are multiple causes of this issue, but for me answer was to remove ~/.pip/.
Details: I had this in my .pip/pip.conf for some reason I can't remember:
$ cat ~/.pip/pip.conf
[global]
use_https = True
index = https://pypi.python.org/pypi
prefix = /home/sam/local/
and was using local versions on Python, Pip installed at ~/local/. For some reason virtualenv installed pip must pick up prefix = /home/sam/local/ setting and pip was being installed there.

Try this: sudo apt install pythonV.v-distutils.
In my case V.v == 3.8.
This worked for me.

Call correct pip in pyvenv environment python3.4

I installed a new pyvenv environment with the following commands:
python3.4 -m venv env
source env/bin/activate
However, when I call which pip, I get the following: /usr/bin/pip. Apparently, the system wide pip installation is still used. If I look at the pyvenv documentation, it states the following:
Changed in version 3.4: Installs pip by default, added the
--without-pip and --copies options
And this is correct, when trying to install pip in my activated environment, I get the following:
Requirement already up-to-date: pip in ./env/local/lib/python3.4/dist-packages
How do I make sure that when I call pip in my activated environment, pyvenv pip is called?

Looks like you (and I in my previous answer) were seeing the effects of a bug. Everything seems to be working in the newer versions of pyvenv-3.4.
$ pwd
~/test
$ pyvenv-3.4 myenv
$ source myenv/bin/activate
(myenv)$ which pip
~/test/myenv/bin/pip

I was having a similar issue, I asked my webhost (WebFaction) and got an excellent response. The Understanding pyvenv and pip in virtual environments with python 3.4 and above page is summarized below.
It seems that you don't have to worry about which pip your virtual environment is using. As long as your virtual environment is active, any packages will be installed in it, regardless of which pip is used.
One thing about Python 3.4 virtual environments is that if the package does not support Python's new "wheel" package format, the package will not install inside the virtual environment directory. It will still maintain a connection with the virtual environment however.
Because of this strangeness, I opted to just use virtualenv instead of pyvenv-3.4 and everything worked as expected.

The issue has been fixed on Ubuntu 14.10.
And if you installed python 3.4 by the following command on Centos6.
yum install http://dl.iuscommunity.org/pub/ius/stable/CentOS/6/x86_64/python34u-3.4.2-1.ius.centos6.x86_64.rpm
You should reopen a new terminal (or relogin your system).
It works for me. Good luck.