The guide explains why isolated environments are crucial when juggling multiple projects that require different dependency versions and shows how Ubuntu ships a lightweight python3‑venv package to simplify this process. It walks the reader through creating a project folder, generating a .venv directory with python3 -m venv, activating it with source ./.venv/bin/activate, and then installing packages such as pip, setuptools, wheel, and flask without polluting the system‑wide site‑packages. The tutorial also highlights common mistakes like running pip outside an activated env, using the wrong Python binary when creating a venv, or unintentionally upgrading global packages, and offers quick sanity checks by listing installed modules inside the environment. By following these steps, developers can keep their projects isolated, avoid “works on my machine” headaches, and enjoy a cleaner development workflow on Ubuntu 22.04 or 20.04.

How to Create a Python Virtual Environment on Ubuntu 22.04 or 20.04

If you’re juggling multiple projects, one of them needs requests version 2.26 while another needs 2.28, then you’ll want an isolated sandbox. A virtual environment keeps your global site‑packages tidy and lets each project get the exact versions it wants.

Installing the venv module

Ubuntu ships a lightweight package that makes virtual environments a breeze.

sudo apt update && sudo apt install python3-venv  # Ubuntu 20.04/22.04

Why this matters: without python3‑venv you can’t create an isolated environment at all.

Picking your project folder

Make a directory for the project and drop into it.

mkdir ~/my‑flask‑app && cd $_

The name isn’t critical, but keeping projects in one place is a habit that saves headaches later.

Creating the environment

Run:

python3 -m venv .venv

-m venv tells Python to run the built‑in module that scaffolds the env. The . prefix means “create it right here” instead of in /usr/local. The resulting .venv/ folder holds its own copy of the interpreter and a fresh site‑packages directory.

Activating the environment

source ./.venv/bin/activate

After this you’ll see (.venv) prefixed to your prompt. That little flag tells you every pip install or Python script runs in isolation. I’ve seen people accidentally push a library into a shared site‑packages folder because they forgot to activate; the project then blows up when another user pulls it.

Installing packages

With the env active:

pip install -U pip setuptools wheel  # upgrade the tools first
pip install flask==2.0.3

Because we’re inside .venv, those packages live only here; no global pollution.

Deactivating when you’re done

deactivate

That restores your shell to the system interpreter. If you forget and run a script that relies on a different library, it’ll use whatever’s installed globally—just another reason to remember to activate.

Common pitfalls

• Running pip install outside an activated env – the package ends up in /usr/lib/python3/dist-packages, and later imports may clash.
• Using python -m venv instead of python3 -m venv on a machine that has both Python 2 and Python 3. The former creates an environment with the wrong interpreter, leading to confusing errors.
• Relying on system‑wide pip to upgrade packages inside the env – pip install --upgrade some_pkg will bump the global copy if you’re not inside a virtual environment.

Quick sanity check

After installing your first package, list what’s in the env:

python - <<'EOF'
import pkgutil, sys
print([m.name for m in pkgutil.iter_modules()])
EOF

If you see flask but not something like django, you’re good to go.

You’re now ready to develop projects without the dreaded “works on my machine” syndrome.