ML-Ingenieure, hört auf mit requirements.txt – steigt heute auf pyproject.toml um

pyproject.toml practical guide

pyproject.toml is important for this topic. This pyproject.toml guide provides practical implementation steps and repeatable best practices.

Applying pyproject.toml consistently improves delivery quality, reliability, and clarity across teams.

See our internal article and official docs.

Jahrelang war requirements.txt die Standardlösung für Python-Abhängigkeiten. Doch das Python-Ökosystem hat sich weiterentwickelt – und wer 2026 noch ausschließlich auf requirements.txt setzt, lässt wertvolle Werkzeuge ungenutzt.

Die Grenzen von requirements.txt

requirements.txt ist im Kern nichts anderes als eine Kurzform für mehrere pip install-Befehle. Für einfache Projekte war das praktisch – für moderne ML-Workflows reicht es nicht mehr:

• Keine Projektmetadaten: Name, Version, Autoren, Lizenz – all das fehlt.
• Kein Build-System: Wie das Paket gebaut wird, bleibt undefiniert – schlecht für reproduzierbare Builds.
• Fragmentierte Konfiguration: Metadaten und Build-Anweisungen waren über setup.py, setup.cfg und MANIFEST.in verstreut.
• Kein Tooling-Support: Linter, Formatter und Test-Frameworks brauchen eigene Konfigurationsdateien.

Willkommen bei pyproject.toml

Mit PEP 518 eingeführt, ist pyproject.toml heute der Standard für modernes Python-Projektmanagement. Eine einzige, deklarative TOML-Datei bündelt alles:

• Projektmetadaten (Name, Version, Autoren, Lizenz, URLs)
• Build-Backend-Deklaration für reproduzierbare Builds
• Abhängigkeiten mit flexibler Versionsspezifikation
• Tool-Konfigurationen für Linter, Formatter und Test-Runner

Beispiel: pyproject.toml für ein ML-Projekt

[project]
name = "awesome-ml-projekt"
version = "0.1.0"
authors = ["Jane Doe <jane@example.com>"]
description = "Ein ML-Projekt nach modernem Python-Standard"
readme = "README.md"
license = {text = "MIT"}
dependencies = [
  "numpy>=1.21,<2.0",
  "pandas>=1.3",
  "scikit-learn>=1.0",
  "matplotlib",
]

[build-system]
requires = ["setuptools>=61.0", "wheel"]
build-backend = "setuptools.build_meta"

[tool.ruff]
line-length = 88
select = ["E", "F", "W", "C90"]

Warum der Umstieg sich lohnt

1. Eine einzige Wahrheitsquelle

Statt setup.py, requirements.txt, setup.cfg und tox.ini parallel zu pflegen, gibt es genau eine Datei. Das reduziert Komplexität und verhindert Inkonsistenzen.

2. Modernes Dependency Management

pyproject.toml funktioniert mit modernen Tools wie pip, Poetry und Hatch – inklusive optionaler Abhängigkeiten und Umgebungsmarkierungen.

3. Tooling direkt integriert

Ruff, Black, pytest und viele weitere Tools lesen ihre Konfiguration direkt aus pyproject.toml. Keine separaten Konfigurationsdateien mehr.

4. Reproduzierbare Builds

Durch explizite Build-Backend-Deklaration sind Builds vorhersehbar und sicher – entscheidend für komplexe ML-Pipelines und CI/CD.

Migration in 5 Schritten

1. Eine pyproject.toml im Projektstamm anlegen.
2. Den [project]-Abschnitt mit Metadaten und bisherigen Abhängigkeiten aus requirements.txt befüllen.
3. Build-Backend festlegen (setuptools oder Poetry).
4. Tool-Konfigurationen hinzufügen (Ruff, pytest, etc.).
5. Alte requirements.txt archivieren oder entfernen, sobald alle Workflows umgestellt sind.

Einen ausführlichen Vergleich beider Ansätze bietet dieser Artikel: pyproject.toml vs requirements.txt.

Fazit

Für ML- und Data-Ingenieure ist der Umstieg auf pyproject.toml kein optionales Upgrade – es ist der Stand der Technik. Eine einzige Datei für Abhängigkeiten, Metadaten und Tooling macht Projekte sauberer, wartbarer und zukunftssicher.