Installation & Virtual Environments

Before we can build TaskFlow, we need Django installed — but installing it directly onto your system's global Python is a habit worth avoiding from day one. This lesson walks through setting up a dedicated virtual environment for the project, installing Django inside it, and recording exactly what got installed so the setup can be reproduced later.

Why Virtual Environments Matter

A virtual environment is an isolated, self-contained copy of Python and its installed packages, kept separate from your system-wide Python installation and from every other project on your machine. Without one, every Python project on your computer shares the same pool of installed packages — which sounds convenient until two projects need different versions of the same package.

Beyond avoiding conflicts, isolated environments also make it far easier to know exactly what a project depends on, which matters a lot once you get to deploying TaskFlow to a server — a topic covered in Environment Configuration and Deployment later in this track.

Creating a Virtual Environment

Python has included the venv module in its standard library since Python 3.3, so no extra installation is needed to create one. From inside your project folder, run:

python -m venv taskflow-env

This creates a new folder named taskflow-env containing a private copy of the Python interpreter and a place for packages to be installed, completely separate from your system Python. You can name this folder anything, but taskflow-env (or simply env or venv) makes its purpose obvious to anyone opening the project later.

Activating the Environment

Creating the environment doesn't put you inside it — you need to activate it first, which tells your terminal session to use that environment's Python and packages instead of the system-wide ones. The activation command differs by operating system:

Once activated, your terminal prompt usually changes to show the environment's name in parentheses, something like (taskflow-env) C:\projects\taskflow>, confirming you're now working inside the isolated environment rather than your system Python.

Installing Django

With the environment active, install Django using pip, Python's package manager:

pip install django

Because your virtual environment is active, this installs Django only inside taskflow-env — your system Python and any other project's environment are left completely untouched.

Verifying the Installation

To confirm Django installed correctly and check which version you have, run:

python -m django --version

This should print a version number such as 5.0.4. If you instead see an error about Django not being found, double-check that your virtual environment is actually activated — it's the single most common cause of this problem.

Freezing Dependencies with requirements.txt

Once Django (and later, any other packages TaskFlow needs) is installed, it's good practice to record the exact installed versions in a file so the environment can be recreated identically elsewhere — on a teammate's machine, a CI server, or a production host.

pip freeze > requirements.txt

This command writes every installed package and its exact version into a plain text file named requirements.txt. Anyone who clones the TaskFlow project can then recreate the exact same environment with a single command:

pip install -r requirements.txt

This file becomes especially important once we reach Environment Configuration and Deployment later in the track — a production server needs to install the exact same dependencies TaskFlow was developed and tested against, and requirements.txt is what makes that reproducible.

Alternatives: pipenv and poetry

venv plus pip freeze is the simplest possible setup, and it's what this track uses throughout. Some teams prefer tools that combine environment management and dependency tracking into one workflow:

• pipenv — manages a virtual environment and a Pipfile together, automatically locking exact versions in a Pipfile.lock
• poetry — handles dependency management and packaging together, using a pyproject.toml file, and is popular for projects that will eventually be published as packages

Either is a reasonable choice for a real team project. We'll stick with plain venv and requirements.txt in this track because they require no extra installation and keep the focus on Django itself rather than tooling choices.