Virtual environments: one interpreter state per project

Goal

Install a project's dependencies without touching the system interpreter or other projects, and be able to throw the environment away and recreate it from the lockfile.

Prerequisites

A Python interpreter of the version the project supports.

Steps

1. Create: python3 -m venv .venv (the directory name is a convention; add it to .gitignore).
2. Use it without activation by calling its interpreter directly: .venv/bin/python -m pip install -r requirements.lock; activation is optional and shell-specific.
3. Install the project itself in editable mode for development: .venv/bin/python -m pip install -e ..
4. Record exact versions with a lockfile and recreate the environment from it in CI and on new machines.
5. Delete and recreate the environment when dependencies drift or the interpreter changes; never repair it by hand.

Expected result

which python inside the environment points to .venv/bin/python; the system Python stays untouched; two projects with conflicting requirements coexist.

Limits and test basis

Virtual environments isolate Python packages, not system libraries or the interpreter build itself; containers or version managers cover those. Environments are not relocatable; recreate rather than copy. Mechanics follow the cited documentation.