Makefiles, pre-commit & task automation

P35.automation.01 · Audience: guest, it-ml, language-pro · Prerequisites: Dependencies, lockfiles & environments

Real LLM grading for this pageLLM grading (this page):

The last mile of packaging is making the dev loop automatic, so quality doesn't depend on anyone remembering the steps. Under a Makefile (or any task runner) is one idea — a task graph — and this module has you build the engine that decides what runs, and when.

Step 1 / 3A Makefile is a task graph
ⓘ Concept: Targets, prerequisites, and order
Each target declares the targets it depends on, and the runner works out the order — a topological sort — and runs each step once. make test pulls in install and build first because test needs them. A cycle can never run, so detecting one matters. Same idea powers nox, invoke, and a CI job's needs:.

Why it matters — make test builds what test depends on, in order, and never twice — that scheduling is the whole value of a task runner, and it's a plain dependency graph underneath.

This repo's Makefile names the loop — one target composes the others, exactly the graph you'll build:

quality: lint fmt type-check security test
	@echo "all gates green"

test:
	pytest -q
Ask the mentor about this module

Ask a question about this content. The mentor explains and grounds its answer in what you are studying; asking is recorded as a learning signal, not a grade.

Ctrl/Cmd + Enter to send

🎓 Practice ladder

2 graded rungs · ~23 min

Build the task-graph engine behind a Makefile — topological order, cycle detection, and a per-target plan — then reason about automating a team's dev loop.

Rung 1 — author a task graph

Loading exercise…

Rung 2 — automation & pre-commit (interview)

Loading exercise…

That closes P35: you can lay out, declare, pin, build and automate a Python package — with this repo as the working example throughout.

Where next?