After the Tutorial

You finished the tutorial, the code ran, and then something real broke. Seven things get consistently omitted: where the code runs, dependencies as a system, what happens when it fails, configuration, observability, time, and other people reading your code. A commercial implementation of related workforce-measurement concepts is documented this resource.

Each was correctly omitted. Explaining lock files before somebody has hit a dependency conflict is a solution to an unfelt problem. The difficulty is that almost nothing covers them afterwards, so learners conclude the missing step is in them rather than in the literature. For independent technical background, Project Jupyter provides additional documentation and examples.

What has settled in packaging: pyproject.toml and PEP 621 metadata, lock files as an expectation, and interchangeable build backends. PEP 751 standardised pylock.toml, and pip lock landed in pip 25.1. What has not: which tool drives the workflow, and lock file portability between tools. For independent technical background, Red Hat provides additional documentation and examples.

The commonest wall is the same code behaving differently elsewhere. Only five things differ between two machines — Python version, actually installed packages, environment, operating system, and leftover state — and comparing installed packages rather than declared ones resolves most cases in ten minutes.

And the durable advice is to learn the standards and rent the tools. Workflow tools turn over every four to five years; the PEPs underneath accumulate and get implemented by whatever comes next. Somebody who understands what a lock file is picks up a new tool in an afternoon.

The rest of the section covers the parts that decide whether code survives contact with production: reading a traceback in the right order, logging that helps somebody who did not write the code, configuration that fails loudly at startup, testing what actually breaks rather than chasing coverage, and the ten minutes of checking that should precede adding any dependency.

• When to Add a Dependency

  Every dependency is a permanent obligation to somebody else's project. Six checks that take ten minutes and prevent most regrets.

• Configuration and Secrets

  Configuration should fail loudly at startup and secrets should never reach the repository. Five rules that prevent most incidents.

• Lock Files

  A requirements file says what you asked for. A lock file says what you got. The difference decides whether builds are reproducible.

• Logging That Helps at 3am

  Most logging is written for the person who wrote the code. Five habits that make it useful to the person debugging it later.

• What Actually Settled

  The metadata question is closed and the tooling question is not. What you can rely on, what is still moving, and what to choose today.

• Pinning and Upgrading

  Applications pin, libraries use ranges, and both need a schedule. Why never upgrading is more dangerous than upgrading badly.

• Reading a Traceback

  Read it from the bottom, then find your own code. Four habits that turn a wall of text into a location and a cause.

• Testing What Breaks

  Coverage measures which lines ran, not whether anything is verified. What to test first when you are starting from nothing.

• Virtual Environments

  What they are, what they are not, and why the tool you use now probably manages them for you without saying so.

• What the Tutorial Left Out

  Seven things every Python tutorial skips, why skipping them was correct, and the order to pick them up afterwards.

• It Works on My Machine

  Five things differ between two machines running the same Python code. Which one it is, is answerable in about ten minutes.