Déplacer un projet Python entre requirements.txt, pyproject.toml et Pipfile
Vous avez hérité d'un projet qui utilise requirements.txt mais le reste de votre équipe est sur Poetry. Ou vous voulez essayer uv, qui attend du pyproject.toml style PEP 621. Ou vous voulez enfin abandonner Pipenv et livrer un vrai lockfile. La partie agaçante n'est jamais le gestionnaire de paquets : c'est les 30 dépendances que vous devez réécrire à la main sans casser un pin de version.
Cet outil convertit les fichiers de dépendances entre formats : requirements.txt, pyproject.toml (les deux styles Poetry et PEP 621 utilisés par uv, PDM et Hatch) et Pipfile. Vous collez un côté, vous obtenez l'autre. Conversion en direct, pas d'upload, rien ne quitte votre navigateur.
Le parser comprend les specifiers de version dans chaque écosystème, ^1.2.3 (caret Poetry) devient >=1.2.3,<2.0.0 en PEP 621, ~=1.2.3 reste un tilde, ==1.2.3 reste pinné. Les dépendances dev restent séparées, les commentaires inline (`# dev`, `# pinned for compat`) font l'aller-retour, les URLs VCS (`git+https://...`), installs éditables (`-e .`) et markers d'environnement (`; python_version >= "3.11"`) sont préservés.
Comment l'utiliser
- Choisissez le format d'entrée dans la barre en haut à gauche : requirements.txt, pyproject.toml ou Pipfile. Collez votre fichier dans la textarea de gauche, le convertisseur démarre immédiatement.
- Choisissez le format de sortie à droite. Vous ne pouvez pas choisir le même format des deux côtés, le bouton correspondant est grisé.
- Si vous exportez vers pyproject.toml, choisissez le style : Poetry (utilisé par Poetry lui-même) ou PEP 621 (utilisé par uv, PDM, Hatch, setuptools). Les deux sont structurés différemment et votre outillage rejettera le mauvais.
- Activez Group dev deps separately pour garder les paquets de développement (linters, test runners) dans leur propre section. Le parser reconnaît les commentaires # dev dans requirements, [tool.poetry.group.dev.dependencies] dans Poetry, [dependency-groups].dev dans PEP 621, et [dev-packages] dans Pipfile.
- Activez Preserve comments pour garder vos notes inline (`# pinned, see CVE-2024-...`) attachées à la bonne dépendance.
- Activez Sort alphabetically si votre équipe utilise des fichiers de dépendances triés. Désactivé par défaut pour que votre ordre original survive.
- Copy le résultat, ou Download comme le bon nom de fichier (`requirements.txt`, `pyproject.toml`, `Pipfile`).
- Swap direction retourne les deux côtés et réinjecte la sortie actuelle comme entrée, utile pour vérifier un aller-retour.
Quand c'est utile
Six situations où coller et cliquer bat la réécriture à la main :
- Migrer un vieux projet vers Poetry. Vous avez un requirements.txt de 40 lignes avec deux sections # dev. Vous collez, basculez vers Poetry pyproject, le groupe dev atterrit automatiquement dans [tool.poetry.group.dev.dependencies].
- Essayer uv sur un projet Poetry existant. uv est PEP 621 natif et 10x plus rapide que Poetry. Vous collez votre pyproject.toml Poetry, basculez la sortie vers PEP 621, vous obtenez le format que uv attend (`[project]` + `dependency-groups`).
- Abandonner Pipenv. Pipfile est moribond. Vous convertissez votre Pipfile en pyproject.toml en deux clics. Le python_version de [requires] atterrit dans requires-python.
- Pipelines CI qui ont besoin de requirements.txt. Votre projet utilise Poetry, mais votre image Docker installe depuis un requirements.txt simple pour le cache. Vous collez le fichier Poetry, obtenez un requirements.txt avec les mêmes pins, vous le déposez.
- Auditer un désordre de versions. Quelqu'un a écrit ^, ~, >= et des pins nus dans le même fichier. Convertissez en requirements.txt pour voir toutes les contraintes de version dans la forme canonique PEP 440 côte à côte.
- Onboarder un nouveau dev. La nouvelle personne utilise uv, le projet utilise Poetry. Vous collez le fichier Poetry, lui envoyez la sortie PEP 621, elle est débloquée en 60 secondes.