Hypermodern Python Tooling

Chapter 5. Managing Projects with Poetry

The preceding chapters introduced the building blocks for publishing production-quality Python packages. So far, you’ve written a pyproject.toml for a project; created an environment and installed dependencies with uv, pip, or pip-tools; and built and published packages with build and Twine.

By standardizing project metadata and build backends, pyproject.toml broke the setuptools monopoly (see “The Evolution of Python Project Managers”) and brought diversity to the packaging ecosystem. Defining a Python package got easier, too: a single well-specified file with great tooling support replaces the legacy boilerplate of setup.py and untold configuration files.

Yet, some problems remain.

Before you can work on a pyproject.toml-based project, you need to research packaging workflows, configuration files, and associated tooling. You have to choose one of a number of available build backends (Table 3-2)—and many people don’t know what those are, let alone how to choose them. Important aspects of Python packages remain unspecified—​for example, how project sources are laid out and which files should go into the packaging artifacts.

Dependency and environment management could be easier, too. You need to handcraft your dependency specifications and compile them with pip-tools, cluttering your project with requirements files. And it can be hard to keep track of the many Python environments on a typical developer system.

The Python project manager ...