Ramblings of an aging IT geek
← Ramblings of an aging IT geek
tooling

the makefile is my universal task runner now

Why I reach for a plain Makefile to drive linting, tests and deploys in projects that contain no C at all, and the one tab-versus-spaces gotcha that still catches me.

A terminal showing a Makefile and a build run

I keep writing Makefiles for projects with no C in them. A Python service, a pile of shell scripts, a static site: doesn't matter. The moment a repo grows more than two "things you run from the command line", I want one place to find them, and make is already on every machine I touch.

The pitch is dull and that's the point. make lint, make test, make deploy. A new starter clones the repo, types make, and the help target tells them what's available. No README archaeology, no "ah, you need to source this script first". The commands are the documentation, and they're the documentation that actually runs.

.PHONY: help lint test
help: ## Show this help
	@grep -E '^[a-z-]+:.*?## ' $(MAKEFILE_LIST) | sort | \
		awk 'BEGIN{FS=":.*?## "}{printf "  %-12s %s\n", $$1, $$2}'

lint: ## Run flake8 over the source
	flake8 src/

test: ## Run the test suite
	pytest -q

The one thing that still gets me, years in, is that recipe lines must start with a real tab. Paste a snippet from a webpage, your editor helpfully expands it to spaces, and you get *** missing separator. Set your editor to keep literal tabs in Makefiles and move on. It isn't elegant, but neither is teaching everyone a new tool when the boring one was already installed.