Let’s look at how to use the Python venv, short for Python virtual environment or virtualenv. You will learn how to create a venv, activate it, delete it, and how a venv works internally. If you want to know why a venv is so useful, please read our main page on virtual environments first.
Creating a Python venv
There are several ways to create a Python virtual environment, depending on the Python version you are running.
Before you read on, I want you to point you to another tool, called pipenv. It combines the functionality of tools that you are about to learn; virtualenv and pip. Further on in this chapter, I will describe pipenv in detail.
Python 3.4 and above
If you are running Python 3.4+, you can use the venv module baked into Python:
$ python -m venv [directory]
This command will create a venv in the specified directory and copy pip and easy_install into it too.
All other Python versions
The alternative that works for any Python version is using the virtualenv package. You may need to install it first, system-wide, with:
$ sudo pip install virtualenv
Once installed, you can create a virtual environment with:
$ virtualenv [directory]
Python venv activation
Linux and MacOS venv activation
On Linux and MacOS, we activate our virtual environment with the source command. If you created your venv in the myvenv directory, the command would be:
$ source myvenv/bin/activate
Windows venv activation
To activate your venv on Windows, you need to run a script that gets installed by venv, like so:
C:\> env\Scripts\activate.bat
That’s it! We’re ready to rock! You can now install packages with pip, but I advise you to keep reading to understand the venv better first. Hang tight, as we’ll get to pip very soon.
How a Python venv works
When you activate a virtual environment, your PATH variable is changed. On Linux and MacOS, you can see it for yourself by printing the path with echo $PATH. On Windows, use echo %PATH%. In my case, on Windows, it looks like this:
/Users/erik/myvenv/bin:/usr/local/bin:/usr/bin:/bin:etcetera
As you can see, the bin directory of my venv is put in front of everything else, effectively overriding all the system-wide Python software. This works because when you enter a command that can’t be found in the current working directory, your OS starts looking at all the paths in the PATH variable. If your venv is there first, the OS will look there first before looking at system-wide directories like /usr/bin.
If you take a look inside the directory of your venv (in this case: myvenv), you’ll see something like this:
You can see that:
- The Python command is made available both as
pythonandpython3, and the version is pinned to the version with which you created the venv by creating a symlink to it. - All packages you install end up in the site-packages directory.
- Activation scripts are generated for multiple shell types (bash, csh, fish)
- Pip is made available under the names pip and pip3
Deactivate the Python venv
If you are done working on your project, it’s a good habit to deactivate its venv. Without deactivating it, all other Python code you execute will also run inside of it.
Deactivating your virtual environment couldn’t be simpler. Just enter this: deactivate. It works the same on all operating systems.
Further resources
- Continue reading, and learn how to install packages with pip
- Pipenv: a better way of managing your venv. I recommend first reading about Pip, though!
- Official venv documentation: If you want to know all the details and command-line options
