Virtual environment

In short: A virtual environment is an isolated workspace for a project with its own version of the programming language and its own libraries. It prevents projects from interfering with each other. This is different from a virtual machine.

In more detail: If project A has library X in version 1 and project B the same in version 2, both would collide in the same system. With a virtual environment each project gets its own set of packages.

In Depth

# Python: venv
python -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install requests
pip freeze > requirements.txt      # record dependencies
deactivate

Language	Tool	Folder
Python	venv, virtualenv, uv, Poetry, Conda	.venv/
JavaScript	node_modules per project (npm, pnpm), versions via nvm	node_modules/
Java	Maven/Gradle fetch dependencies per project, JDK choice with SDKMAN	~/.m2, build/
Ruby	Bundler, rbenv	vendor/bundle
All	Dev containers, Nix

• How it works: The environment has its own folder with an interpreter copy or link and its own package store. On “activating”, the PATH points to this folder.
• Dependency file: requirements.txt, package-lock.json, pom.xml record what was installed so others get the same result.
• Not in Git: The environment folder belongs in .gitignore. Only the dependency list is committed.
• Never install globally (sudo pip install); it pollutes the system.
• Distinction: Virtual environment = separate packages on the same operating system. Containers and VMs additionally isolate parts of the operating system.
• Symptom: “Works on my machine, not on yours”: usually missing or different package versions. A clean environment with pinned versions solves that.

See also: Virtual machine (VM), Sandbox, Docker