La fonctionnalité de formatage de code arrive expérimentalement dans uv

• Les nouvelles versions de uv proposent de manière expérimentale une fonctionnalité de formatage de code
• La commande uv format s’appuie en interne sur le formateur de Ruff pour appliquer un style cohérent au code Python
• Il devient possible d’organiser son code simplement avec uv seul, sans outil séparé supplémentaire
• Les utilisateurs peuvent ajuster finement le comportement du formatage via des arguments additionnels
• Comme il s’agit encore d’une fonctionnalité expérimentale, la syntaxe de commande, la gestion des erreurs et d’autres aspects peuvent encore évoluer

---

Aperçu

La dernière version de uv (0.8.13) introduit uv format, une commande expérimentale que les développeurs Python attendaient depuis longtemps. Cette fonctionnalité permet de mettre en forme le style du code avec uv seul, sans avoir à gérer un outil de formatage supplémentaire dans le projet.

Qu’est-ce que uv format ?

• La commande uv format permet le formatage du code Python via l’interface de uv
• En interne, elle invoque le formateur de Ruff pour réorganiser automatiquement le code de manière cohérente

Remarques pour les développeurs

Charlie Marsh (développeur de uv) l’a expliqué ainsi sur Hacker News :

Ruff et uv ne fusionnent pas, et restent des outils distincts
L’objectif est simplement d’améliorer l’expérience afin que les utilisateurs puissent utiliser le formateur sans le percevoir comme un outil séparé
La relation est similaire à celle entre cargo fmt et rustfmt dans l’écosystème Rust

Mode d’emploi

• Il faut utiliser uv en version 0.8.13 ou supérieure
• Exécuter la commande uv format à la racine du projet revient à lancer ruff format
• Le mode d’exécution suit l’interface de commande de uv

Transmission d’arguments supplémentaires

• Avec la forme uv format -- [arguments supplémentaires], il est possible de définir des options détaillées transmises à Ruff
• On peut ainsi profiter à la fois de la simplicité de uv et de la configuration fine de Ruff

Indications sur la phase expérimentale

• La fonctionnalité est actuellement en phase expérimentale, et la syntaxe de commande ou la manière d’intégrer la structure du projet pourraient évoluer à l’avenir
• La gestion des erreurs, le format de sortie et d’autres points doivent aussi être améliorés en continu
• La fonctionnalité devrait évoluer en tenant compte des retours des utilisateurs

Conclusion

• Si un projet Python a besoin d’un formatage de code simple et cohérent, uv format mérite clairement d’être essayé
• Comme il s’agit d’une introduction expérimentale, l’utiliser puis partager son retour peut contribuer à l’évolution future de uv

[GN⁺]

Avis Hacker News

• Ce serait peut-être mieux si ruff fusionnait avec ty ; uv devrait se concentrer sur la gestion des paquets ou des projets, et ne pas aller jusqu’au style du code ; à mon avis, le seul cas où uv devrait modifier des fichiers source, c’est lors des mises à jour de dépendances (PEP 723)
  • Je veux clarifier que ruff et uv ne fusionnent pas et resteront des outils séparés ; le but est simplement d’offrir une expérience plus simple aux utilisateurs qui ne veulent pas se préoccuper d’un formateur séparé ; c’est comparable à Rust, où cargo fmt exécute rustfmt en interne
  • C’est une imitation de la façon dont cargo fmt existe dans l’écosystème Rust
  • L’objectif est fondamentalement de faire de uv un gestionnaire de paquets Python complet, tout en laissant chaque outil utilisable séparément si nécessaire ; autrement dit, uv veut être le cargo de Python, et si l’on a seulement besoin d’un vérificateur de types rapide, on choisit ty, si l’on veut seulement un formateur/linter, on choisit ruff ; dans cette optique, fusionner ruff et ty n’aurait pas beaucoup de sens
  • Je me demande aussi si, un jour, ty finira par être intégré à uv ; comme tout cela vient d’astral.sh, c’est peut-être la vision, mais pour l’instant ty ne semble pas encore prêt
  • L’étape suivante logique serait à mon avis d’introduire quelque chose comme uv lint qui exécuterait ty en interne ; idéalement, on devrait pouvoir préparer un projet Python (formatage, lint, tests, publication) avec une commande standard ou une petite série de commandes ; c’est peut-être la vision derrière tout cela
• J’aime beaucoup utiliser uv, mais je m’inquiète un peu de le voir grossir inutilement ; par exemple, de nombreuses sous-commandes prennent énormément de drapeaux particuliers, dont certains produisent presque le même résultat (uv run --no-project et uv run --active, par exemple) ; plutôt que d’ajouter sans cesse de nouvelles fonctionnalités, j’aimerais qu’on se concentre davantage sur les outils existants et sur l’amélioration de la documentation
  • Rendre un projet Python stable, reproductible et portable est vraiment très difficile ; en théorie, uv sync est très utile car il reconstruit un ensemble de paquets reproductible, mais des paquets complexes comme torch-tensorrt ou flash-attn peuvent malgré tout varier selon l’environnement ; la communauté Python a souvent tendance à personnaliser le problème avec des réponses du type « chez moi ça marche », mais le coût nécessaire pour distribuer des logiciels de manière sûre, répétable et fiable ne disparaît jamais ; au final, quelqu’un paiera ce coût plus tard dans un contexte plus contraint ; essayer de satisfaire tous ces utilisateurs et toutes ces exigences d’exploitation est vraiment difficile
  • Je ne vois pas bien pourquoi ajouter des sous-commandes à uv serait considéré comme de l’embonpoint ; uv est déjà un outil complexe, et il est bien documenté ; si les commandes sont aussi intuitives et explicites, leur ajout me paraît tout à fait naturel
  • Quand on parle de uv ainsi, j’ai l’impression d’entendre « la commande make a trop de cibles »
  • Je me demande si ces options sont intégrées au binaire principal, ou si elles fonctionnent comme des binaires séparés, à la manière d’apt ou cargo
• Je pense que cette mise à jour est clairement un bon choix ; je ne comprends pas pourquoi autant de gens s’opposent à une meilleure direction ; bien sûr, on peut dire « on peut déjà le faire d’une façon un peu plus pénible », mais justement, c’est « un peu plus pénible »
  • Je ne pense pas que le fait que uvx ruff format fasse un mot de plus soit vraiment un problème ; en revanche, ce qui peut être plus déroutant, c’est qu’on ne sache plus clairement quel formateur est réellement exécuté, si ruff est installé automatiquement, ou si, comme avant, l’outil est téléchargé et mis en cache
  • Je suis tout à fait d’accord avec ça ; ce serait encore mieux si on permettait de configurer le formateur dans pyproject
  • Mon plus gros reproche, c’est qu’à l’heure actuelle il ne semble pas y avoir de prise en charge d’autres formateurs ; si mon projet utilise black, uv format ne fonctionnera pas
• Personnellement, j’attends beaucoup de ce changement, car il devrait rendre le formatage du code radicalement plus simple pour ma petite équipe, principalement composée d’actuaires ; uv a déjà eu un impact important sur l’adoption de Python et l’onboarding, donc tout moyen de faciliter l’amélioration de la qualité du code est bienvenu ; bien sûr, on peut utiliser ruff séparément ou configurer pre-commit, mais le modèle mental simple de uv <fonction> aide énormément l’équipe ; j’aimerais aussi que l’intégration avec d’autres formateurs soit possible, et si cela allait jusqu’au formatage des modèles SQL/dbt, ce serait parfait ; pour l’instant, je vais l’essayer et voir jusqu’où cela peut aller
  • Si l’on a besoin d’autant de formatages multiples, il vaut peut-être mieux utiliser quelque chose comme un Makefile ou un justfile ; ainsi, on peut lancer just format pour formater Python/SQL/Bash/TypeScript en une seule fois
• Ça donne un peu une impression de surcharge fonctionnelle ; cela fait plus d’un an que j’utilise uv de plus en plus et j’en vois les avantages, mais ce n’est toujours pas mon premier choix, et ce genre de changement ne va probablement pas augmenter ma préférence pour lui
  • Je serais curieux de savoir ce qui pose précisément problème dans cette approche ; Go, Rust et Elixir procèdent tous ainsi, et cela rend la configuration et l’utilisation des projets bien plus simples dans leurs écosystèmes ; cela permet à la communauté de se concentrer sur un outillage commun et offre un point d’entrée cohérent, autant pour les débutants que pour les experts
  • Dans ce cas, je serais curieux de savoir quel outil tu préfères le plus
• J’ai l’impression qu’un jour les fonctionnalités de ruff seront intégrées à uv et à ty ; le linting pourrait devenir plus intelligent s’il était pris en charge par ty, qui comprend mieux la base de code, tandis que le formatage conviendrait bien à uv, dont le but principal est la gestion de projet
  • Comme ty est déjà dans le même dépôt que ruff, l’intégration ne semble pas si lointaine
• Un gestionnaire de paquets est indispensable pour installer des paquets destinés à l’environnement d’exploitation, mais le mélanger avec des outils purement dédiés au développement me donne l’impression d’un « piège séduisant mais dangereux » ; bien sûr, Go et Rust font aussi cela, mais en y réfléchissant au fond, je ne suis pas sûr que ce soit une si bonne architecture
  • Ça va peut-être sonner très négativement, mais en tant que gros utilisateur de cargo, j’aimerais qu’il y ait davantage de ce genre de « mauvaises idées » ; si uv finit par jouer le rôle de cargo pour Python, l’expérience de développement Python deviendra incroyablement meilleure ; après plus de 25 ans à utiliser Python et à contourner ses nombreuses lacunes, je trouve extrêmement satisfaisant de pouvoir désormais tout faire avec uv sans trop se poser de questions
• Le nouveau uv format est en pratique un raccourci pour uv run --with ruff ruff
• J’aime vraiment cette direction ; si cela ne tenait qu’à moi, je l’appellerais uv fmt, et j’ajouterais aussi quelque chose comme uv vet à la feuille de route
• Il existe déjà beaucoup d’outils de formatage de code éprouvés, donc je ne vois vraiment aucune raison d’introduire cela ; on a juste l’impression d’ajouter des fonctionnalités, et je ne pense pas l’inclure dans mes pipelines avant un bon moment
  • uv format est plutôt un frontend pour ruff format, rien de plus ; cela n’ajoute pas un nouveau formateur
  • J’aimerais que les gens comprennent bien qu’il s’agit simplement d’un raccourci pour utiliser facilement ruff format, que beaucoup de personnes utilisent déjà