Interpreter Isolation with venv

### What `python -m venv` actually builds `python -m venv .venv` asks the *currently running* interpreter to build a small directory tree. On POSIX you get `.venv/bin` containing `python`, `python3` and a version-suffixed name such as `python3.14` — symlinks to (or, with `--copies`, copies of) the interpreter that created the environment — plus the activation scripts and a `pip` entry point. On Windows the same content lives in the `Scripts` directory. Beside it sit `.venv/lib/python3.14/site-packages`, which starts almost empty, and `.venv/pyvenv.cfg`, a short text file recording the base installation. That is the entire environment: somewhere to put packages, an entry point, and a note saying which real Python it borrows a standard library from. ### Activation edits the shell, and only the shell Read the activate script and there is no magic in it. It saves the current `PATH` into a private variable and prepends the environment's `bin` directory; it exports `VIRTUAL_ENV` pointing at the environment root and, on current CPython, `VIRTUAL_ENV_PROMPT`; it unsets `PYTHONHOME` if it was set, because a stale `PYTHONHOME` would send the interpreter looking for its standard library somewhere else; it prefixes the prompt string; and it defines a shell *function* called `deactivate` that puts every one of those saved values back. It does **not** set `PYTHONPATH`. It does **not** modify `sys.path`. It does not copy or install anything, and it cannot reach into a process that is already running. So the single thing activation buys you is name lookup: typing `python`, `pip` or an installed console script finds the environment's copies first, because that directory is now at the front of `PATH`. Real convenience — but convenience, not mechanism. ### Why calling the interpreter directly is equivalent When any CPython process starts it resolves the path of its own executable, walks up one directory, and looks for `pyvenv.cfg`. If it finds one, it treats the directory containing the executable's parent as `sys.prefix` and records the original installation in `sys.base_prefix`; the environment's `site-packages` then lands on `sys.path` and the standard library continues to be loaded from the base installation. That lookup depends on nothing but the path of the binary you ran. `.venv/bin/python -c "import sys; print(sys.prefix)"` therefore prints the environment whether or not any shell variable was ever touched, and `.venv/bin/python -m pip install ...` installs into that environment for the same reason. ### Where the distinction stops being pedantry * **CI pipelines.** Most runners execute each step in a fresh shell, so `source .venv/bin/activate` in step one is simply gone by step two. Calling the absolute interpreter path in every step always works. * **Service managers, cron and supervisors.** These launch a process directly, often with no shell at all, or with a minimal `/bin/sh` that has no `source` builtin. The correct configuration names `/srv/app/.venv/bin/python` as the executable; there is nothing to activate. * **Makefile recipes.** Each recipe line runs in its own shell, so activation on one line has evaporated by the next. * **Editors and debuggers.** They ask you for an interpreter *path*, not for an activation step, because the path is what actually selects the environment. * **Subprocesses.** A child launched with a scrubbed or replaced environment loses the `PATH` edit, so a bare `python` inside it resolves to whatever the system offers. ### The failures people actually hit Using `source` in a POSIX `sh` script that does not have it (use `.` instead); PowerShell refusing to run the activation script under a restrictive execution policy; stacking activations of two different environments and expecting one `deactivate` to unwind both; deleting the environment directory while it is still on `PATH`, so `python` resolves to a path that no longer exists; and assuming activation gives isolation it never promised — a globally exported `PYTHONPATH` still injects its directories, activated or not. ### The sentence to say in an interview Activation is a `PATH` edit with a prompt change attached; the interpreter you execute is what decides the environment. Everything else follows from that. ### What reads VIRTUAL_ENV, if not the interpreter The variable is not useless — it is a *signal for tooling*. Prompt themes read it to show which environment you are in, some installers refuse to touch a global installation while it is set, and editors and shell helpers use it to guess a default interpreter. None of that is the interpreter's own behaviour, and none of it changes how imports resolve. Keep the two apart in your head: `VIRTUAL_ENV` is documentation for humans and tools, while `pyvenv.cfg` beside the executable is what the interpreter actually consults. ### Windows, briefly The same environment carries three activation scripts in its `Scripts` directory: one for a POSIX-style shell, a `.bat` file for the classic command prompt, and an `Activate.ps1` for PowerShell, which a restrictive execution policy can refuse to run. All three do the same job — reorder `PATH`, export `VIRTUAL_ENV`, decorate the prompt — and all three are equally optional, because invoking the environment's `python.exe` by path selects the environment exactly as it does on POSIX.