A virtual environment is a project-specific Python environment with its own package installation directory, built from an existing Python installation. It lets a quant researcher change a notebook's dependencies without changing the packages used by another project's pricing scripts.
The useful boundary is the package set. A virtual environment is neither a security sandbox nor an operating-system container. Code still runs with the user's ordinary file and network permissions.
Which Python runs the calculation?
Suppose a pricing project and a reporting project need incompatible releases of the same library. Give each project its own environment and install its requirements there. Switching directories alone does not select an environment: the interpreter running the code determines which packages it normally sees.
Python's standard-library
venv uses a selected base Python and, by default, excludes the base installation's and user's site-packages. The --system-site-packages creation option deliberately relaxes that boundary. The environment still uses the base installation's standard library; it does not download a different Python release. PEP 405 explains this package-directory separation.
Observed disposable check on Python 3.14.4: NumPy was available in the base runtime but absent from the new environment. The package boundary leaves ordinary operating-system permissions in place.
Create, select, then install
A typical local workflow creates
.venv with python -m venv .venv, using the intended installed Python. Activation puts the environment's executable directory first on the shell's search path. It is a convenience: an explicit interpreter path works without activation. The Python documentation describes both routes.On macOS/Linux,
.venv/bin/python -m pip install -r requirements.txt explicitly runs pip through that environment's Python. On Windows, the corresponding interpreter is .venv\Scripts\python.exe. These are command patterns, not installation results. Prefer the module form python -m pip to a bare pip when selecting the interpreter matters, and select the same environment in your editor or notebook kernel. The Python Packaging User Guide covers creation and installation.The following macOS/Linux example makes a temporary environment, runs its interpreter directly and removes the temporary directory on exit. It uses
with_pip=False so the check bootstraps no pip and installs no packages. The two output lines were checked on Python 3.14.4; the base runtime had NumPy installed.import subprocess
import tempfile
import venv
probe = (
"import sys, importlib.util; "
"print('Inside venv:', sys.prefix != sys.base_prefix); "
"print('NumPy available:', importlib.util.find_spec('numpy') is not None)"
)
with tempfile.TemporaryDirectory() as folder:
environment = folder + "/env"
venv.EnvBuilder(with_pip=False).create(environment)
python = environment + "/bin/python"
result = subprocess.check_output([python, "-I", "-c", probe], text=True)
print(result, end="")
# Inside venv: True
# NumPy available: FalseHere
sys.prefix != sys.base_prefix identifies the virtual environment. The separate -I flag ignores Python environment variables and the user site directory and excludes the current directory from the module search path; it makes this probe less dependent on local import-path customisations. The absence of NumPy is expected: creating the environment did not copy the base runtime's packages.Keep the recipe, recreate the directory
Isolation is one part of dependency management. It does not automatically pin package versions, retain yesterday's market data, identify the code revision or record model settings. A reproducible environment needs those records as appropriate, including package pinning.
Treat
.venv as disposable. Preserve the dependency specification and the required Python version alongside the project, and recreate the environment at the destination. Copying its directory to another machine or path is unreliable because installed scripts can contain absolute interpreter paths and packages can depend on the platform. Keep research code and data outside .venv, so rebuilding the environment does not remove them.For a guided local walkthrough, Virtual Environments covers creation, interpreter selection and installation. Reproducible Environments extends the record to code, data and run settings. Both offer public previews; the full lessons require membership.