Virtual Environment

A Python virtual environment provides a separate installation location for a project’s packages. By default, it does not expose packages installed in the base interpreter’s system site-packages. This lets two projects use different library versions without repeatedly replacing one shared installation.

Isolation has a boundary. A virtual environment still uses a Python interpreter and the host operating system; it is not a security sandbox or a complete operating-system image. Native libraries, environment variables, files, and external services can still affect the program. Creating the environment also does not decide which dependency versions should be installed.

Activation changes shell settings so commands such as python resolve to the environment’s executable. It is a convenience, not a requirement: invoking the environment’s Python by its full path selects it directly. Check the actual interpreter used by a scheduled job instead of assuming it inherited an interactive terminal’s activation.

Treat the environment as something to recreate. Record the interpreter requirements and dependencies, install them in a new environment, and run the application’s checks. Copying an existing environment folder to another location or machine can break paths and installed scripts. A dependency lock helps select packages, while deployment verification checks whether that selection works in the target environment.

Reference: Python venv documentation. For worked examples, see Python for Data Engineers.