Virtual Environments & pip Interview Questions & Answers

A virtual environment is a self-contained directory with its own Python interpreter and its own site-packages, so each project gets an isolated set of dependencies. Isolation matters because two projects often need different versions of the same package — without venvs, installing for one breaks the other, and installing globally can even break system tools.

# Project A needs Django 3, Project B needs Django 5.
# Separate venvs let both coexist without conflict.
python -m venv .venv        # creates an isolated environment

A venv keeps dependencies per project and out of the global interpreter, making builds reproducible and avoiding "works on my machine" version clashes. Use one for every project.

Create one with the standard-library venv module, then activate it so the shell uses the venv's python and pip. The activation command differs by OS; deactivate returns to the global interpreter.

python -m venv .venv            # create (folder named .venv)

source .venv/bin/activate       # activate on macOS / Linux
.venv\Scripts\activate          # activate on Windows

which python                    # -> .../.venv/bin/python while active
deactivate                      # leave the venv

Once active, pip install puts packages inside the venv only. Add .venv/ to .gitignore — you commit the dependency list, not the environment itself.

pip install fetches packages from PyPI into the active environment. A requirements.txt lists a project's dependencies (often with pinned versions) so anyone can recreate the same environment with one command.

pip install requests            # install latest
pip install "requests==2.31.0"  # install a specific version

pip install -r requirements.txt # install everything listed in the file

# requirements.txt
requests==2.31.0
rich>=13.0

Committing requirements.txt makes installs reproducible across machines and CI. Install into an activated venv, never globally with sudo pip.

pip freeze prints every installed package with its exact pinned version in requirements.txt format, so you can capture the current environment. Redirect it to a file to snapshot dependencies.

pip freeze                          # list installed pkgs == versions
pip freeze > requirements.txt       # snapshot the current environment
pip list                            # similar, but human-readable table

A caveat: pip freeze records everything installed, including transitive dependencies, which can make the file noisy. Many teams instead hand-curate direct dependencies (or use a lock-file tool) and keep pip freeze for capturing a known-good full snapshot.

An editable install links your project into the environment in place instead of copying it, so edits to the source take effect immediately without reinstalling. It's the standard way to work on a package you're developing locally.

pip install -e .                # install the current project, editable
pip install -e ".[dev]"         # editable + optional 'dev' extras

Because the install points at your working tree, changing the code updates the imported package right away — no rebuild needed. Use -e for your own package under development, and a normal pip install for third-party dependencies.

pyproject.toml is the modern, standardized config file (PEP 518/621) for a Python project — it declares the build system, project metadata, and dependencies in one place, replacing the older setup.py/setup.cfg split. Most modern tools (build, pip, linters, formatters) read it.

[project]
name = "myapp"
version = "0.1.0"
dependencies = ["requests>=2.31", "rich"]

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

With dependencies declared here, pip install . (or -e .) reads them directly, so a separate requirements.txt becomes optional. It's the recommended starting point for any new packaged project.