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
Related
I'm on an OS Catalina and I'm trying to install and run Mephisto (see https://github.com/facebookresearch/mephisto/blob/master/docs/quickstart.md). I created a python3 virtual environment and then went to the directory and ran
sudo pip3 install -e .
This seems to have run fine as I can now run mephisto and see the list of commands and options. However when I run mephisto register mturk it throws No module named 'mephisto.core.argparse_parser' because of an import statement in the python file. This seems like a general issue of a module installing but not importing the module properly, but would appreciate help in how to fix it. Is it because my $PYTHONPATH is currently empty?
Mephisto Lead here! This seems to have been a case of unfortunate timing, as we were in the midst of a refactor there and some code got pushed to master that should've received more scrutiny. We'll be moving to stable releases via PyPI in the near future to prevent things like this!
I created a python3 virtual environment and then went to the directory and ran
sudo pip3 install -e .
You should not have used sudo to install this library, if you meant to install it in a virtual environment. By using sudo the library probably got installed in the global environment (not in the virtual environment).
Typically:
create a virtual environment:
python3 -m venv path/to/venv
install tools and libraries in this environment with:
path/to/venv/bin/python -m pip install Mephisto
use python in the virtual environment:
path/to/venv/bin/python -c 'import mephisto'
use a tool in the virtual environment:
path/to/venv/bin/mephisto
Is it because my $PYTHONPATH is currently empty?
Forget PYTHONPATH. Basically one should never have to modify this environment variable (this is almost always ill-informed advice to get PYTHONPATH involved).
Check the __init__.py file is in the module's file directory. If not try creating an empty one.
I had python2 installed in my ubuntu (19.04) and I wanted to get it upgraded to 3.7. I installed the 3.7 but still the version showed as 2.7. but I could run python3 and go to the console and python3.7 executable was available in /usr/bin. Did try all the tricks available in internet without any luck. then I decided to delete python2.7 executable from the /usr/bin and now I cannot even run pip as it tries to find the deleted 2.7 I guess. Getting the following message.
bash: /usr/bin/pip: /usr/bin/python: bad interpreter: No such file or directory
I don't know why it's still trying to find 2.7 like ex girl friend when 3.7 is installed and available in the machine.
Did you set up a path for python 3.7 in your .bashrc file? If not, try that and that should help.
Usually a path is something like:
$ export PATH=$HOME/Nek5000/bin:$PATH
First, run an update to make sure that there aren’t newer versions of the required packages.
sudo apt update --fix-missing
Next, you can try forcing Apt to look for and correct any missing dependencies or broken packages. This will actually install any missing packages and repair existing installs.
sudo apt install -f
(Source)
Also, always remember - never install directly in global environment. You should always create a local environment first(i recommend venv) as there are very high chances you can break something globally.
You can create a local environment by -
python3 -m venv tutorial-env
where tutorial-env is the name of your environment.
To activate this environment, you should run
source tutorial-tutorial-env/bin/activate
I am developing a simple python package (on macOS 10.14) and I have problems in setting the instructions how to install it. Right now the package is not available anywhere yet, but think of it as a dummy "hello world" package with a dummy "hello world" function inside a dummy "hello world" module. Of course it has a proper setup.py script that would allow users to install and uninstall the package with pip.
When I install and test it myself everything works fine, the problem is not related to the package itself.
The issue is that I cannot make conda virtual environments and pip work together... Next to my setup.py script there is a environment.yaml file that specifies the dependancies required for my package. Based on this file I create a virtual environment with:
conda env create --prefix ENV -f environment.yaml
I have conda 4.7.12 with Python 3.7.3 inside so the virtual environment has it's own pip. So I activate the virtual environment and explicitly call the pip inside to install my package in the virtual environment:
/Users/my_name/Desktop/dev_dir/ENV/bin/pip install . --user
The installation is successful and the package can be imported. However when I deactivate the virtual environment with conda deactivate and run python interpreter from the conda base environment (version 3.6.9) I can still load my package! For some reason it is available outside of that particular virtual environment...
Later, when I run the 'inner' pip from conda base shell:
/Users/my_name/Desktop/dev_dir/ENV/bin/pip uninstall pkg
The removal seems to go through as well. I get a message:
Uninstalling pkg-0.0.0.9000:
Would remove:
/Users/my_name/.local/lib/python3.7/site-packages/pkg-0.0.0.9000.dist-info/*
/Users/my_name/.local/lib/python3.7/site-packages/pkg/*
Proceed (y/n)? y
Successfully uninstalled pkg-0.0.0.9000
suggesting that the package was indeed installed in a directory .local, outside conda virtual environments.
And the best for the last: even after this uninstallation when I run python interpreters (regardless of which environment from) and I try to import pkg it still works! when I then type pkg in the interpreter I get the path to my development directory:
>>> import pkg
>>> pkg
<module 'pkg' from '/Users/my_name/Desktop/dev_dir/pkg/__init__.py'>
Could someone please help me disentangle this mess? I would like to have my package installed inside the virtual environment, nicely isolated. And also - it should be gone after uninstallation, right?
PS. PYTHONPATH variable is never set anywhere at any stage, I have been checking that...
when I then type pkg in the interpreter I get the path to my development directory
This can only happen if:
You modified your PYTHONPATH to include /Users/my_name/Desktop/dev_dir which you didn't do
You are running the interpreter while you are in the folder /Users/my_name/Desktop/dev_dir, seems likely as you called it your development folder.
Check the output of print(sys.path), which lists all directories that are searched when doing import (standard locations + PYTHONPATH) and also print(os.getcwd()) as the current working directory is also searched
You tried installing your package to your activated conda environment using
/Users/my_name/Desktop/dev_dir/ENV/bin/pip install . --user
Looking at [the docs](https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-user] however:
--user
Install to the Python user install directory for your platform. Typically ~/.local/
So the --user option is messing with your intention to install into the currently active environment. But pip actually does that by default when run inside a virtual environment. So simply do:
conda activate <your envname>
pip install .
#FlyingTeller already correctly identified the issue. I just wanted to point out that you could further streamline your process by adding the installation for your package into your YAML definition. For example,
name: my_env
channels:
- defaults
dependencies:
- python=3.7.3
- pip
- pip:
- -e /Users/my_name/Desktop/dev_dir/pkg
This is also further in line with the best practices (see "Using Pip in a Conda Environment").
Just wanted to hopefully clear some up by telling you this keeps happen to many and if you forget the rule that is NO root install with conda, all rules for your files might change and suddenly it keeps asking for sudo AND fails. Conda = NO SUDO! Hope you got it fixed!
You have to add the pip package to your environment (see https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html), otherwise the packages will be installed by the global pip installation such that those packages can be accessed by all environments.
Therefore, create an environment using
conda create --name exampleenv pip
instead of
conda create --name exampleenv
I created a virtual environment in my new directory with virtualenv env and then in Windows Git Bash ran env/Scripts/activate, which seemed to work. I didn't notice my virtualenv being displayed in parens at the beginning of the line (question1: can I set it up to work like that?), so to check if it was indeed activated I ran pip -V which gave me:
pip 9.0.1 from c:\tools\python2\lib\site-packages (python 2.7)
Shouldn't that be giving the directory of my virtualenv rather than site-packages? I also ran pip list and it gave me a list of installs that I had (naughtily) installed globally for a different project. So I can only assume my virtualenv did not activate and I don't know why that is.
Your suspicions are correct. Try source Scripts/activate. What you did will run the command in a new and temporary shell instance.
I am trying to install a Python package with this command
pip install <name of package>
I'm getting permission errors and I'm not sure why. I could run it with sudo, but someone told me that was a bad idea, and I should use a virtualenv instead.
What is a virtualenv? What does it do for me?
Running with the system Python and libraries limits you to one specific Python version, chosen by your OS provider. Trying to run all Python applications on one Python installation makes it likely that version conflicts will occur among the collection of libraries. It's also possible that changes to the system Python will break other OS features that depend on it.
Virtual environments, or "virtualenvs" are lightweight, self-contained Python installations, designed to be set up with a minimum of fuss, and to "just work" without requiring extensive configuration or specialized knowledge.
virtualenv avoids the need to install Python packages globally. When a virtualenv is active, pip will install packages within the environment, which does not affect the base Python installation in any way.
In Python 3.3 or later, you can create a virtualenv as follows:
$ python3 -m venv ENV_DIR
For Windows, you should replace python3 with the full path to python.exe:
>C:\Python34\python.exe -m venv ENV_DIR
(This is a typical Python installation; your system may vary.)
In older versions of Python, including Python 2, one of the following commands should work in most cases:
$ virtualenv ENV_DIR
$ venv ENV_DIR
$ pyvenv ENV_DIR
$ pyvenv3 ENV_DIR
ENV_DIR should be a non-existent directory. The directory can have any name, but to keep these instructions simple, I will assume you have created your virtualenv in a directory called venv (e.g. with python3 -m venv ./venv).
To work in your virtualenv, you activate it:
$ . ./venv/bin/activate
(venv)$
Or use this if you have a windows system:
$ venv\Scripts\activate
The (venv) in the shell prompt lets you know which virtualenv you have activated, but you can turn this feature off if you do not like it. You can run all the usual Python commands, and they will be local to your virtualenv:
(venv)$ pip install requests numpy
[...]
(venv)$ python
[...]
>>> import requests
>>> import numpy as np
>>>
python will run the version of Python that you installed into your virtualenv, so (for example) you don't have to type python3 to get Python 3. The Python that it runs will have access to all the standard library modules and all the packages you installed into the virtualenv, but (by default) none of the packages installed in the system-wide site-packages directory.
This last rule is important: by restricting your virtualenv to only use locally-installed packages, you can ensure that you control exactly which dependencies your project is using, even if some new system-wide package gets installed or updated next week. If you like, you can get a listing of your installed packages:
(venv)$ pip freeze
requests==2.13.0
numpy==1.12.0
(venv)$
pip can also parse this format and install from it, and it will install the same versions, even if updates have been released in the meantime:
(venv)$ pip freeze >requirements.txt
(some-other-venv)$ pip install -r requirements.txt
[...]
(some-other-venv)$ python
>>> import requests
>>> import numpy as np
>>>
You can get out of the virtualenv by deactivating it:
(venv)$ deactivate
$ python
[...]
>>> import requests
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named 'requests'
You can create as many virtualenvs as you like, and they won't interfere with each other, nor with your system packages. A virtualenv is "just" a directory with a bunch of binaries and scripts under it, so you can remove a virtualenv the same way you remove any directory (rm -r venv on Unix). If the virtualenv is activated when you remove it, you may confuse your shell, so it's probably a good idea to deactivate first in that case.
Some times you are not given root privileges and you might end up not being able to use sudo. Many other times, it's not advisable to use sudo to install packages as it might overwrite some package which might be in use by some other applications.
Virtualenv can help you create a separate environment where you don't need root privileges as well as be able to tailor the environment according to your need. It consists of self-contained python installation which only interacts with your specific created environment.
So basically, it gives you a bit of freedom as well as avoid damaging (or modifying) the root environment which might be hosting many old functionalities of old applications.
Installation is pretty easy too.
Installing packages with sudo pip will install packages globally, which may break some system tools.
By install globally it means you will install your packages in place like /usr/lib/python2.7/site-package so if some packages need a previous version of your python packages, this action may break it.
virtualenv allows you to avoid installing Python packages globally by making an isolated python environment. That means it will install packages just in your desire project folder.
On mac and linux
Install
python3 -m pip install --user virtualenv
Creating a Virtual Env: Go to your desired project folder
python3 -m virtualenv env
Activating a virtualenv: In your desired project folder
source env/bin/activate
After activating you can install your packages using pip.
For more information about using it in Windows:
How to use virtualenv in Windows
I am going to break your question into two parts.
What is a virtualenv?
Python has its own way of downloading, storing, and resolving site packages. But Python can not differentiate between different versions in the site-package directory. Packages will be installed in one of the directories, whose name can be found by running the site.getsitepackages() commands.
>>> import site
>>> site.getsitepackages()
This means package_v2.0.1 and package_v3.0.1 have to be in the same directory with the same name i.e. package, which is obviously not possible. Now, you may ask why we would need the same package with different versions on our system. This is because multiple projects may require different versions of Python packages or even different Python versions themselves. So there was a need to have something which will resolve these conflicts and Virtualenv came into the picture to solve this issue.
What does it do for me?
It isolates the environment for Python projects so that each project can have its own dependencies.