Python-Projekt zwischen requirements.txt, pyproject.toml und Pipfile umziehen
Du hast ein Projekt geerbt, das requirements.txt nutzt, aber der Rest deines Teams ist auf Poetry. Oder du willst uv ausprobieren, das eine pyproject.toml im PEP-621-Stil erwartet. Oder du willst endlich Pipenv loswerden und ein echtes Lockfile shippen. Das Nervige ist nie der Package-Manager: es sind die 30 Dependencies, die du per Hand umschreiben musst, ohne einen Version-Pin zu zerreißen.
Dieses Tool konvertiert Dependency-Files zwischen Formaten: requirements.txt, pyproject.toml (sowohl Poetry- als auch PEP-621-Stil, der von uv, PDM und Hatch genutzt wird) und Pipfile. Eine Seite pasten, die andere kommt raus. Live-Konvertierung, kein Upload, nichts verlässt deinen Browser.
Der Parser versteht Version-Specifier in jedem Ökosystem: ^1.2.3 (Poetry-Caret) wird zu >=1.2.3,<2.0.0 in PEP 621, ~=1.2.3 bleibt Tilde, ==1.2.3 bleibt gepinnt. Dev-Dependencies bleiben getrennt, Inline-Kommentare (`# dev`, `# pinned for compat`) überleben den Round-Trip, VCS-URLs (`git+https://...`), editable Installs (`-e .`) und Environment-Marker (`; python_version >= "3.11"`) bleiben erhalten.
So nutzt du das Tool
- Input-Format wählen in der Leiste oben links: requirements.txt, pyproject.toml oder Pipfile. Dein File in die linke Textbox pasten, der Konverter startet sofort.
- Output-Format rechts wählen. Beide Seiten können nicht das gleiche Format haben, der passende Button ist ausgegraut.
- Exportierst du nach pyproject.toml, wähl den Stil: Poetry (von Poetry selbst genutzt) oder PEP 621 (von uv, PDM, Hatch, setuptools). Die zwei sind anders strukturiert und dein Tooling rejected den falschen.
- Schalte Group dev deps separately an, um Dev-Pakete (Linter, Test-Runner) in einer eigenen Section zu halten. Der Parser erkennt # dev-Kommentare in requirements, [tool.poetry.group.dev.dependencies] in Poetry, [dependency-groups].dev in PEP 621 und [dev-packages] in Pipfile.
- Schalte Preserve comments an, um deine Inline-Notizen (`# pinned, see CVE-2024-...`) an der richtigen Dependency zu halten.
- Schalte Sort alphabetically an, wenn dein Team sortierte Dependency-Files nutzt. Per Default aus, damit die Original-Reihenfolge überlebt.
- Kopier das Ergebnis oder lad es runter unter dem passenden Dateinamen (`requirements.txt`, `pyproject.toml`, `Pipfile`).
- Swap direction dreht die beiden Seiten und schiebt den aktuellen Output zurück in den Input, nützlich zum Prüfen eines Round-Trips.
Wann das nützlich ist
Sechs Situationen, in denen Pasten und Klicken besser ist als Handarbeit:
- Altes Projekt zu Poetry ziehen. Du hast eine 40-zeilige requirements.txt mit zwei # dev-Sections. Du pastest sie, schaltest auf Poetry pyproject, die Dev-Gruppe landet automatisch in [tool.poetry.group.dev.dependencies].
- uv auf einem bestehenden Poetry-Projekt testen. uv ist PEP-621-nativ und 10x schneller als Poetry. Du pastest deine Poetry-pyproject.toml, schaltest den Output auf PEP 621, und kriegst das Format, das uv erwartet (`[project]` + `dependency-groups`).
- Pipenv hinter sich lassen. Pipfile stirbt aus. Du konvertierst dein Pipfile in zwei Klicks zu pyproject.toml. Die python_version aus [requires] landet in requires-python.
- CI-Pipelines, die requirements.txt brauchen. Dein Projekt nutzt Poetry, aber dein Docker-Image installiert aus einer schlichten requirements.txt wegen Caching. Du pastest das Poetry-File, kriegst requirements.txt mit denselben Pins, fertig.
- Versionierungs-Chaos auditieren. Jemand hat ^, ~, >= und nackte Pins in demselben File geschrieben. Konvertiere zu requirements.txt, um alle Constraints in der kanonischen PEP-440-Form nebeneinander zu sehen.
- Neuen Entwickler onboarden. Die neue Person nutzt uv, das Projekt nutzt Poetry. Du pastest das Poetry-File, schickst ihr den PEP-621-Output, sie ist in 60 Sekunden unblocked.