Creating a Django Virtualenv
October 19, 2021
Let me first say that creating a Python virtual environment is not strict requirement for any project, including Django projects. But there are lots of good reasons to do it. In my mind, the most important reason is that creating a virtual environment makes managing dependencies so much easier.
The ability to simply delete a venv directory and re-install any package as needed is wonderful. I delete and re-create virtual environments all the time. It’s great. And I know that doing so won’t break anything on my host machine’s Python environment. This is especially true for any Django virtualenv.
# Confirm virtualenv is installed
virtualenv -h
# Install virtualenv if not already
# sudo pip3 install virtualenv
# Create a new virtual environment called venv
virtualenv -p python3 venv
# Activate the virtual environment
source venv/bin/activate
# Once the venv is activated, install Django
pip3 install djangoGetting started
I won’t be able to create a virtual environment unless I have virtualenv installed on my machine. There are more than a few ways to install it, but on Ubuntu 18.04 I generally run the following command with pip3:
sudo pip3 install virtualenvOnce it’s done installing, I should be able to access the virtualenv cli. I can run the following command from the terminal to see the available commands:
virtualenv -hWhich will return something that looks like this:
Usage: virtualenv [OPTIONS] DEST_DIR
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-v, --verbose Increase verbosity.
-q, --quiet Decrease verbosity.
-p PYTHON_EXE, --python=PYTHON_EXE
The Python interpreter to use, e.g.,
--python=python2.5 will use the python2.5 interpreter
to create the new environment. The default is the
python2 interpreter on your path (e.g.
/usr/bin/python2)
...Creating a Django Virtualenv
At this point I can create a Django virtualenv for my project. But, where should the venv (or whatever I decided to call it) go? The answer is that it can go anywhere. As long as the virtual environment is activated when I run any django related commands it doesn’t matter where the virtualenv directory is.
From the command line I’ll run:
virtualenv -p python3 venvThe above command with create a new virtual environment called venv in the current directory. I like to include the -p python3 flag to ensure that I’m using Python3 in my venv. This is especially important when the operating system has multiple Python versions installed.
The name of the virtual environment can be anything. I tend to go with venv, but I can be django-venv, virtualenv, or bobby-sue. Giving it some context might be helpful, though.
If for some reason I was sharing a virtual environment via version control, then the location does matter. It should be in the project root directory where the .git directory exists. But, it’s not often I share the virtual environment on a project. I usually just end up creating my own based on the requirements.txt for a given project.
The other issue with sharing the virtual environment is that I get into a situation where I need a parent directory to contain the top level django project created by the django-admin startproject myProject command. So I end up with a myProject/myProject/ structure which is a little awkward. Not really the end of the world, though.
Activating the Virtual Environment
An important step that I almost always forget is activating the virual environment. This is done using the source command with the activate script in the virtual environment directory.
source venv/bin/activateOn most *nix based operating systems, I’ll see the name of the virtual environment in parenthesis at the start of the command line. It’ll look something like:
(venv) notimedad@ubuntu:~/workspace/myProject$Which is how I know the Django virtualenv is activated and I can install packages to it instead of to my host machine.
(venv) notimedad@ubuntu:~/workspace/myProject$ pip3 install django