Introduction

Using Python 3 in an isolated environment is one of the first habits that makes Python projects predictable. It prevents dependency conflicts, makes installs reproducible, and lets you control exactly which interpreter a project uses. The main detail that trips people up is that there are two related tools, venv and virtualenv, and both can create Python 3 environments if you point them at the right interpreter.

venv Versus virtualenv

If you already have Python 3 installed, the simplest option on modern Python is the built-in venv module:

python3 -m venv .venv
source .venv/bin/activate
python --version

That creates a project-local environment in .venv and activates it. After activation, python and pip point to the isolated environment rather than the system interpreter.

virtualenv is an older, still useful tool that works similarly but must be installed separately. It is especially common in older tutorials and multi-interpreter workflows.

1python3 -m pip install --user virtualenv
2virtualenv -p python3 .venv
3source .venv/bin/activate
4python --version

Both approaches can create a Python 3 environment. The practical difference is that venv ships with Python, while virtualenv provides extra compatibility and convenience features for some setups.

Choosing the Right Python 3 Interpreter

The most important part is not the tool name. It is the interpreter path you use.

On machines with several Python versions installed, commands such as python, python3, and py may point to different executables. Before creating the environment, verify the interpreter you want:

python3 --version
which python3

On Windows, the launcher is often the clearest option:

py -3 -m venv .venv
.\.venv\Scripts\Activate.ps1
python --version

If you specifically need Python 3.11 or 3.12, use that exact interpreter path when creating the environment. The environment inherits its Python version from the interpreter that built it.

Installing Packages Inside the Environment

After activation, install dependencies normally with pip:

python -m pip install --upgrade pip
python -m pip install requests
python -m pip freeze > requirements.txt

Using python -m pip is safer than calling pip directly because it guarantees that the package installer belongs to the currently active interpreter.

A small test script confirms that the environment is isolated:

1import sys
2import requests
3
4print(sys.executable)
5print(requests.__version__)

When you run that script inside the environment, sys.executable should point into .venv rather than the global Python installation.

When to Recreate the Environment

Virtual environments are disposable. That is a feature, not a weakness. If dependencies drift or the environment becomes inconsistent, deleting it and recreating it is often faster than repairing it manually.

A common workflow looks like this:

• create .venv
• activate it
• install from requirements.txt or pyproject.toml
• work normally
• recreate the environment if dependency state becomes messy

Because the environment is reproducible from dependency definitions, you should avoid committing the environment folder itself to Git.

Common Pitfalls

• Creating the environment with the wrong interpreter, then wondering why the Python version is not what you expected.
• Installing packages before activation, which puts them into the global environment instead.
• Calling pip from a shell that is not using the active environment.
• Committing .venv into version control. The environment directory should usually be ignored.
• Mixing virtualenv and venv commands in old notes without checking which tool is actually installed.

Summary

• You can create a Python 3 environment with either python3 -m venv .venv or virtualenv -p python3 .venv.
• The Python version inside the environment comes from the interpreter used to create it.
• Activate the environment before installing packages.
• Prefer python -m pip so package installs target the correct interpreter.
• Treat virtual environments as disposable, reproducible project infrastructure.