Skip to content

Managing-Virtual-Environments.md

Latest commit

 

History

History
95 lines (69 loc) · 4.16 KB

Managing-Virtual-Environments.md

File metadata and controls

95 lines (69 loc) · 4.16 KB
Raw

Managing Virtual Environments

Creating, activating, and deactivating isolated Python environments with venv and virtualenv, and why isolation is essential for security tooling.

Overview

A virtual environment is a self-contained directory holding its own Python interpreter link and site-packages. Installing into it leaves the system interpreter untouched. For a pentester or analyst this isolation is not optional: it lets you pin exact tool versions per engagement, avoid dependency conflicts between projects, and keep the OS interpreter clean so the box stays stable. The built-in venv module covers almost all needs; virtualenv is a faster third-party alternative with extra features.

Syntax

# Create, activate, deactivate (built-in venv)
python3 -m venv .venv
source .venv/bin/activate     # bash/zsh;  .venv\Scripts\activate on Windows
deactivate

Explanation

When a venv is active, python and pip resolve to the copies inside .venv/bin, and your shell prompt is prefixed with (.venv). Deactivating restores the previous interpreter.

Command Effect
python3 -m venv .venv Create an environment in .venv/
source .venv/bin/activate Put the venv's bin first on PATH
deactivate Leave the environment
python -m venv --upgrade-deps .venv Create with up-to-date pip/setuptools
rm -rf .venv Delete the environment (it is disposable)

venv (standard library) vs virtualenv (PyPI):

  • venv ships with Python 3, is enough for most projects.
  • virtualenv is faster to create, supports older interpreters, and can seed newer pip. Install with pip install virtualenv, then virtualenv .venv.
# Isolation proof: package exists in venv, not in system interpreter
source .venv/bin/activate
pip install scapy
python -c "import scapy; print('in venv:', scapy.__version__)"
deactivate
python3 -c "import scapy"      # ModuleNotFoundError — system stays clean

Output

in venv: 2.5.0
Traceback (most recent call last):
  ...
ModuleNotFoundError: No module named 'scapy'

Security Use Cases

  • Per-engagement environments — a acme-2026/.venv with pinned tools produces identical results on a retest months later.
  • Avoiding system pollution — installing scapy, impacket, pwntools into a venv keeps the OS interpreter (and Kali's own tooling) unbroken.
  • Reproducible payloads — freeze the venv to a requirements.txt so a teammate or CI rebuilds the exact toolchain.

Best Practices

  • One venv per project/engagement; name it .venv and add it to .gitignore.
  • Recreate rather than repair a broken venv — they are disposable.
  • Pin dependencies with pip freeze > requirements.txt (see [[Pip-Package-Manager]]).
  • Activate the venv before installing anything; verify the prompt shows (.venv).

Common Mistakes

  • Forgetting to activate, then pip install-ing into the system interpreter (PEP 668 now blocks this on Debian/Kali).
  • Committing the .venv/ directory to git — it is large, machine-specific, and unnecessary; commit requirements.txt instead.
  • Moving/renaming the project folder and expecting the venv to still work — the interpreter paths inside are absolute; recreate it.

Practical Lab

Goal: prove environment isolation.

  1. python3 -m venv .venv && source .venv/bin/activate.
  2. pip install requests inside the venv.
  3. python -c "import requests; print(requests.__version__)" — succeeds.
  4. deactivate, then python3 -c "import requests" against the system interpreter and observe the ModuleNotFoundError.
  5. pip freeze > requirements.txt, delete .venv, recreate it, and reinstall with pip install -r requirements.txt.

References

Related

  • [[Pip-Package-Manager]]
  • [[Pyenv]]
  • [[Project-Structure-Best-Practices]]
  • [[Installing-Python-on-Linux]]
  • [[Python-Environment-Setup/Readme|Python Environment Setup]] — module index
  • [[Readme|Python for Security Professionals]] — course home