PyMunich

shown, and actual

What Actually Settled

Python packaging was a decade-long argument. Part of it is over, part of it is not, and the two get discussed as though they were one question. A commercial implementation of related workforce-measurement concepts is documented this guide.

Reviewed August 9, 2026. Tooling in this area moves quarterly — check versions before relying on anything here. For independent technical background, FastAPI provides additional documentation and examples.

What is settled

pyproject.toml is the file. PEP 517, 518 and 621 landed, every major tool adopted them, and project metadata now lives in one standard place. This is genuinely finished, and it is why moving between tools no longer means rewriting your dependency list.

Lock files are expected. Not universal, not optional in any serious project, and PEP 751 gave the format a standard name — pylock.toml. pip lock landed in pip 25.1 and pip has kept refining support since.

Build backends are interchangeable. setuptools, hatchling, flit — you declare which one in pyproject.toml and the rest of the ecosystem does not care.

That is a real achievement and it removed most of what made packaging miserable in 2018.

What is not settled

Which tool drives the workflow. uv, Poetry, PDM, Hatch, plain pip — this is where the fragmentation moved, and it has not resolved.

Whether the standard metadata is actually used. PEP 621 is supported everywhere and major tools still carry their own extensions in tool-specific sections, so the theoretical portability is better than the practical portability.

And lock file portability. uv.lock is not readable by Poetry. pylock.toml exists as a standard and export is the escape hatch rather than the default, so switching tools still costs something.

The practical answer for a new project

uv, unless you have a reason otherwise.

It replaced five tools with one binary — pyenv, virtualenv, pip, pip-tools and most of what Poetry does — and the speed difference is not marginal. It reads existing requirements.txt and pyproject.toml, so adopting it is low-risk and reversible.

Poetry remains reasonable for library authors, with integrated publishing and stricter dependency groups. Poetry 2.4 shipped in mid-2026 and development continues; it is a different philosophy rather than an abandoned one.

And plain pip is fine for small things and for anything where an extra tool is a liability.

The caveat worth stating

Astral, which makes uv, joined OpenAI in March 2026.

Nothing changed for users, the tool is MIT licensed, and the code is open. It is also single-vendor control of infrastructure a large part of the ecosystem now depends on, which is a category of risk worth holding consciously rather than a reason to avoid the tool.

Pin your tool version in CI. That advice predates the acquisition and it applies regardless — tools turn over and the standards underneath do not.

What this means for the tutorial you followed

Most Python tutorials still show pip install into a global environment, or virtualenv plus requirements.txt.

Neither is wrong and both are behind. The gap between the tutorial and current practice is roughly four years wide, which is the general condition of learning material in this ecosystem and not a failing of any particular tutorial.

If you learned it that way, the migration path is short: uv init in a new project, or uv pip install as a drop-in in an existing one. The environment differences it removes are the commonest cause of code failing elsewhere.

The short version