Part 6 of 8 · 2 min read
Running the checks, and working like a professional
The three commands that define "the project works", and what teams add on top.
Here is the whole routine on a fresh copy of the project, with real output:
$ python -m venv .venv
$ source .venv/bin/activate
(.venv) $ pip install -e ".[dev]"
(.venv) $ pytest -q
... [100%]
3 passed in 0.10s
(.venv) $ mypy src
Success: no issues found in 3 source files
(.venv) $ triage "Where is my order?"
{
"id": "demo",
"messages": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "Where is my order?"
}
]
}
~11 tokens
pytest runs the tests, mypy src checks the types, and the triage command is the small program itself. (The ~11 tokens is a rough guess: the code divides the number of characters by four. Level 1 explains what tokens really are.) All three should pass on a fresh clone. Make that your definition of "the project works".
What you will use daily at work
| Practice | What it looks like |
|---|---|
| One environment per project, always | python -m venv .venv, or uv sync. Never install into your system Python. |
| Commit the lock file | A uv.lock or requirements.lock so everyone, and CI, installs the same versions. |
| A formatter and linter | Teams commonly use ruff to format and lint on save and in CI, so nobody argues about style. |
| A type checker in CI | mypy or pyright runs on every pull request. |
| Pre-commit hooks | The formatter, linter and a secret scanner run automatically before each commit. |
| One command to start | A short README section, or a task runner (make test, just test, uv run pytest) so a new teammate is productive in minutes. |
| Update dependencies on purpose | A tool such as Dependabot or Renovate opens pull requests for new versions, and CI says if they are safe. |
Draft: to be checked against the current documentation of uv, ruff and the tools named here before this page goes live.
Interview angle
Answer in your head first, then open it.
Why use a virtual environment?
Isolation: each project controls its own library versions, and the environment can be deleted and rebuilt at any time.
Type hints are not enforced at run time. So why bother?
A checker finds mistakes before running, editors give better help, and Pydantic uses the same hints to validate external data.
What is the difference between a dependency range and a lock file?
The range says what is allowed. The lock records what was actually tested and deployed.
Why put code under src/?
So that tests import the installed package, as users do, and packaging mistakes show up early.
Where do secrets go?
Not in the code or the repository: in environment variables, with a .env.example that lists only the names.