Consider using pyenv instead of venv

[simoncozens]

This encapsulates the Python version, and we often get problems with people using the wrong Python. (I stole this idea from SIL.)

[janbrasna]

Alternatively more modern uv venv https://docs.astral.sh/uv/pip/environments/ can also pull the necessary Python version if not available already.

[madig]

Seconding the use of uv. It is the best thing in Python management ever. The Makefile can stop managing the venv manually by just prepending uv run to all commands dealing with Python in some way. If you switch from requirements files to a pyproject.toml and use a uv.lock lockfile, you don't even have to uv venv and uv pip install anything. Any uv run command will do everything for you automatically and you can stop thinking about it. A .python-version file will pin your Py version.

[RickyDaMa]

Also strongly in favour of uv, it covers several areas the current template doesn't, and improves on others:

1. It respects pinned Python versions by default, and will install a Python version if needed. You can ask font designers to just install uv (which has an install script, not ideal but better than nothing), instead of a Python version
2. Significantly faster venv creation & dependency installation
3. Cross-platform requirements.txt generation (and also cross-Python version, if we wanted that)
4. Simplified venv activation thanks to uv run

And yeah if we used a pyproject.toml then we get one place to specify required Python version support and dependencies, and then can use uv's own lockfile format to ensure consistency (which has a single command to create a venv and install everything into it, uv sync). The advantages here are smaller, mostly just consolidating a diverse spread of files (requirements.in, requirements.txt, .python-version) into fewer places, and giving devs quicker/simpler CLI invocations (not something that most font developers will care about, admittedly)