Python Virtual Environments — Django 1.11 & 4.0 Conflict

Every Python developer hits the same wall eventually: you install a package for one project, and suddenly another project breaks. Or your colleague sends you code that works on their machine but explodes on yours with a cryptic version error. These aren't rare edge cases — they're the everyday reality of working with Python, and they happen because Python installs packages globally by default, meaning every project on your computer shares the same pool of libraries.

Virtual environments solve this by giving each project its own isolated bubble. Inside that bubble, you can install exactly the packages — and exactly the versions — that project needs, without touching anything else. Delete the bubble when the project is done and your computer is as clean as when you started.

By the end of this article you'll know how to create a virtual environment from scratch, activate and deactivate it, install packages inside it, save a record of those packages so teammates can replicate your setup exactly, and spot the traps that catch beginners off guard. No prior experience needed — we'll build everything step by step.

Why Global Package Installation Is a Ticking Time Bomb

When you first install Python and run pip install requests, that library lands in a single global location on your computer. Every Python script you ever write shares that same copy. Sounds convenient — until it isn't.

Picture this: your first project uses requests version 2.20. Six months later you start a new project that needs requests version 2.31 because it uses a feature that didn't exist before. You upgrade globally. Your old project breaks. You downgrade to fix the old project. The new project breaks. You're stuck in a loop with no clean way out.

This exact scenario has a name in software: dependency conflict. It's not hypothetical — it's the single most common source of pain for Python beginners and professionals alike.

Virtual environments break this cycle permanently. Each environment is a self-contained folder that holds its own Python interpreter and its own set of packages. Project A's requests 2.20 and Project B's requests 2.31 can coexist peacefully on the same machine because they live in completely different folders and never meet.

Here's a subtle but important detail: virtual environments don't copy the entire Python installation. They create symlinks (Mac/Linux) or shortcuts (Windows) to the Python binary and then add their own site-packages folder. This keeps environments lightweight — typically 10-20 MB plus whatever packages you install.

Creating and Activating Your First Virtual Environment

Python ships with a built-in module called venv (short for virtual environment). You don't need to install anything — it's already there, waiting. You create a virtual environment with a single terminal command, and from that moment on, that folder is your project's private kitchen.

The general pattern is: python -m venv <name-of-environment>. The name is just a folder name — most developers use venv or .venv (with a dot prefix so the folder is hidden by default on Mac/Linux).

Once created, you need to activate it. Activating tells your terminal 'for every command I run from now on, use the Python and pip inside this folder, not the global ones'. The activation command is slightly different depending on your operating system, but the effect is identical.

After activation your terminal prompt usually changes to show the environment name in parentheses — that's your visual confirmation that you're inside the bubble. When you're done working, deactivate drops you back to the global environment.

What's actually happening when you activate? The activation script modifies your shell's PATH environment variable, adding the .venv/bin directory to the front. Since shells search PATH in order, python now resolves to .venv/bin/python first. The VIRTUAL_ENV environment variable is also set so tools can detect which environment is active. The deactivate command restores the original PATH.

Freezing Dependencies So Your Team Gets Identical Setups

Creating a virtual environment is half the job. The other half is making sure anyone else — a teammate, your future self on a new laptop, a deployment server — can recreate that exact same environment instantly.

That's what requirements.txt is for. It's a plain text file that lists every package your project depends on, along with the exact version numbers. Think of it as a recipe card: instead of 'bring the ingredients', you hand someone the full recipe and they produce the identical dish.

You generate it with one command: pip freeze > requirements.txt. The pip freeze part lists all installed packages with their versions; the > requirements.txt part saves that list into a file. To recreate the environment from that file, anyone runs pip install -r requirements.txt.

This is not optional polish — it's professional practice. Every serious Python project has a requirements.txt (or its more advanced cousin pyproject.toml). Without it, your project only works on your machine, which is the definition of a broken workflow.

A subtle but important detail: pip freeze includes transitive dependencies — packages that your direct dependencies depend on. That's intentional — you want the entire dependency graph locked, not just what you explicitly installed. If you want only your top-level dependencies, consider using pip-tools or poetry, but for most projects, pip freeze is sufficient.

Another best practice: maintain two requirements files — requirements.txt for production dependencies and requirements-dev.txt for development tools (pytest, black, mypy, pre-commit). Your production server doesn't need testing frameworks.

A Real-World Mini Project Tying It All Together

Theory is fine, but let's build something real inside a virtual environment so the whole workflow clicks. We'll write a small script that fetches the current weather for a city using the requests library — a package we install inside a virtual environment, not globally.

This example shows the complete developer workflow you'll repeat on every Python project you ever build: create environment → activate → install dependencies → write code → freeze requirements → deactivate. Once this muscle memory kicks in, you'll do it automatically.

Pay attention to the Python script itself too. It runs perfectly inside the virtual environment because requests is installed there. If you deactivate the environment and try to run the same script with the global Python, it would fail with ModuleNotFoundError: No module named 'requests' — unless you also happen to have it globally. That's virtual environment isolation working exactly as intended.

The script uses a free weather API (Open-Meteo) that requires no API key — perfect for learning. It demonstrates error handling for network issues and API errors, showing real production considerations even in a demo.

Frequently Asked Questions