Environments, Packaging & Tooling

Python’s greatest strength — a massive ecosystem of packages — is also its most common source of pain. Two projects on one machine will want conflicting versions of the same library, and “works on my machine” is almost always an environment problem. Professional Python starts with getting this under control.

Virtual environments: isolation by default

A virtual environment is an isolated directory with its own Python and its own installed packages. One per project. Nothing leaks between projects, and nothing pollutes your system Python.

python -m venv .venv          # create
source .venv/bin/activate      # activate (macOS/Linux)
pip install requests           # installs only into this env

The moment you install packages globally with pip, you’ve made a future mistake. Treat “create a venv” as the reflexive first step of any new project.

Pinning: reproducible installs

“It worked last week” breaks when a dependency releases a new version. You prevent this by pinning exact versions so every install is reproducible.

The old-school way is a requirements.txt with exact versions. The modern standard is pyproject.toml, which declares your dependencies, and a lock file that records the exact resolved versions (including transitive dependencies) for byte-for-byte reproducible installs.

The modern toolchain

The Python tooling landscape consolidated dramatically over the last few years. The current professional defaults:

• uv — an extremely fast, all-in-one replacement for pip, virtualenv, and dependency resolution. uv venv and uv pip install are drop-in and dramatically faster; uv also manages Python versions and lock files.
• Ruff — a linter and formatter that replaces the old stack of flake8, isort, and much of Black, running in milliseconds.
• pytest — the de-facto testing framework; plain functions with assert, no boilerplate.
• mypy / pyright — static type checkers (covered in the typing lesson).

uv venv && source .venv/bin/activate
uv pip install -r requirements.txt
ruff check . && ruff format .
pytest

A sane project layout

myproject/
├── pyproject.toml      # metadata + dependencies
├── src/
│   └── myproject/      # your package
│       └── __init__.py
└── tests/
    └── test_core.py

The src/ layout prevents a classic bug where your tests accidentally import the local source folder instead of the installed package — a difference that hides packaging mistakes until production.

Why this matters for the role

Senior engineers are trusted to set up projects that other people can run. Reproducible environments, fast CI, and consistent formatting aren’t busywork — they’re what makes a team’s velocity survive past the first month. Getting the foundation right here pays compounding interest across everything that follows.

When to reach for this

Variations

Try it

These are workflow exercises. The code is mostly shell and config because the point is to make Python projects reproducible before you write feature code.

# Modern path
uv venv
source .venv/bin/activate
uv pip install -r requirements.txt

# Built-in fallback when uv is not available
python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

[project]
name = "ai-prep-demo"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
  "httpx==0.27.2",
]

[dependency-groups]
dev = [
  "pytest==8.3.3",
  "ruff==0.6.9",
]

[tool.ruff]
line-length = 88

[tool.pytest.ini_options]
testpaths = ["tests"]

uv sync --dev
ruff check .
ruff format .
pytest

[project]
name = "image-worker"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
  "requests==2.32.3",
]

uv lock
uv sync --locked
pytest