uv est la meilleure innovation apparue dans l’écosystème Python depuis 10 ans

(emily.space)

29 points par GN⁺ 2025-10-30 | 7 commentaires | Partager sur WhatsApp

uv simplifie radicalement l’installation de Python et la gestion des environnements virtuels, en résolvant les problèmes complexes de configuration d’environnement dans l’écosystème Python
Écrit en Rust, il combine vitesse et stabilité, et gère l’installation des versions de Python, la gestion des paquets et la résolution des dépendances avec une seule commande
Il détecte automatiquement pyproject.toml pour configurer l’environnement du projet, et uv sync permet de reproduire un environnement de développement strictement identique entre les membres d’une équipe
Grâce à des commandes comme uv run, uv add et uvx, il est possible d’exécuter sans activer l’environnement virtuel, d’ajouter des paquets et de faire des exécutions ponctuelles
En garantissant une installation cohérente de Python et une exécution uniforme, uv est considéré comme un tournant majeur pour la productivité des développeurs et l’efficacité de la collaboration

Présentation de uv

uv est un outil gratuit et open source de gestion de Python développé par Astral, dont l’objectif est de simplifier les processus complexes de configuration d’environnement
- Astral est l’équipe à l’origine d’outils de développement Python comme Ruff
- uv prend en charge l’installation des versions de Python, l’installation de paquets, la gestion des environnements virtuels et la résolution des dépendances, tout en étant nettement plus rapide que les outils existants
Développé en Rust, il offre d’excellentes performances et fonctionne sur presque toutes les plateformes, dont macOS, Linux et Windows

Installation et utilisation de base

L’installation est très simple et peut se faire avec une seule ligne de commande curl ou PowerShell
- Linux/Mac: curl -LsSf https://astral.sh/uv/install.sh | sh
- Windows: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
Comme il ne modifie pas l’installation Python existante, on peut l’essayer en toute sécurité

Gestion de l’environnement de projet

uv gère automatiquement un environnement virtuel pour chaque projet Python et configure l’environnement en reconnaissant le fichier pyproject.toml
- pyproject.toml définit notamment la version de Python, la liste des dépendances, ainsi que le nom et la version du projet
- Exemple :
```
[project]  
name = "my_project"  
version = "1.0.0"  
requires-python = ">=3.9,<3.13"  
dependencies = ["astropy>=5.0.0", "pandas>=1.0.0,<2.0"]  
```
- Cette approche fournit une définition de l’environnement plus claire et plus standardisée que pip

Créer un nouveau projet

La commande uv init permet de créer facilement un nouveau projet
- Elle génère automatiquement les fichiers essentiels comme pyproject.toml et README.md
- Différents modes d’initialisation sont pris en charge via des options comme --bare et --package
- Les options détaillées sont consultables avec uv init --help

Synchroniser un projet existant

Si le projet contient un pyproject.toml, la commande uv sync permet de l’utiliser immédiatement
- Installation automatique de la version de Python
- Création d’un environnement virtuel dans le répertoire .venv
- Génération de uv.lock, qui enregistre les informations de version exactes de tous les paquets
Avec la commande uv run, il est possible d’exécuter des scripts Python sans activer l’environnement
- Exemples : uv run myscript.py, uv run jupyter lab

Gestion des dépendances et des versions de Python

La commande uv add numpy>=2.0 permet d’ajouter et de gérer automatiquement des dépendances
- Il n’est pas nécessaire de modifier directement pyproject.toml
La commande uv python pin 3.12.9 permet de figer une version précise de Python, ce qui garantit la reproductibilité de l’environnement

uvx : exécution ponctuelle rapide

uvx est une commande qui permet d’exécuter immédiatement des outils sans configuration d’environnement séparée
- Exemples : uvx ruff, uvx jupyter lab, uvx --with pandas,pyarrow ipython
- Grâce au cache, les réexécutions sont très rapides, ce qui est utile pour les travaux expérimentaux
Les développeurs peuvent ainsi mettre en place facilement des environnements d’exécution temporaires sans être contraints par les environnements virtuels

Si cela ne vous convainc toujours pas : note personnelle

Pendant le développement de The Astrosky Ecosystem, uv a été adopté pour unifier les environnements Python sur plusieurs OS
- Il permet à tous les développeurs et serveurs d’utiliser des versions strictement identiques de Python et des dépendances
- uv gère également l’environnement Python dans GitHub Actions et sur les serveurs de production
Grâce à uv, les problèmes de décalage entre les environnements d’installation et de test ont disparu, et la collaboration entre développeurs s’est simplifiée

Conclusion

uv élimine à la racine la complexité de l’installation et de la gestion de Python, et permet aux développeurs de collaborer de manière fiable dans un environnement identique
Grâce à sa rapidité et à la stabilité apportée par Rust, uv est considéré comme « la plus grande innovation survenue dans l’écosystème Python depuis 10 ans »

7 commentaires

kkksss 2025-11-06

Je pensais que pdm était presque identique à uv, mais on n'entend pas beaucoup parler de pdm.

ztaka 2025-11-02

Je l’utilise beaucoup en ML et sur le Web, et j’espère que uv deviendra vite une technologie banale haha.

yuntae 2025-10-30

J’ai l’impression que les posts sur uv ne changent plus vraiment beaucoup maintenant.

pmc7777 2025-10-30

Maven et Gradle aussi..

doolayer 2025-10-30

Quand on voit un dépôt avec seulement requirements et sans pyproject.toml, ça paraît déjà d'une autre époque, haha ;

GN⁺ 2025-10-30

Avis Hacker News

On entendait autrefois que l’outillage Python était suffisant, mais voir les développeurs Python découvrir les avantages d’un écosystème basé sur des lockfiles comme avec npm, cargo ou bundler, ça fait vraiment plaisir
npm a aussi ses problèmes, mais les installations cohérentes et les fichiers de verrouillage sont de très bonnes idées
- Il n’y a rien de plus angoissant que de devoir exécuter le projet Python de quelqu’un d’autre
  C’est étonnant que la gestion des environnements soit restée aussi pénible aussi longtemps
- Je me demande pourquoi cela a pris autant de temps
  Je me demande si l’échec de tant de tentatives vient simplement de la difficulté de la gestion de paquets, ou s’il fallait du financement VC
- J’utilisais déjà depuis longtemps pip freeze > requirements.txt et pip install -r requirements.txt
  Si on n’utilise pas de plages de versions, requirements.txt joue en pratique le rôle de lockfile
  Donc l’engouement actuel pour les « lockfiles officiels » me paraît un peu exagéré
- npm aussi a longtemps vécu sans lockfile
  L’arrivée de yarn a beaucoup contribué à l’amélioration de npm
- Je fais du développement web depuis 1998, et je pense que PNPM est bien meilleur que npm
  C’est plus rapide, plus efficace et déterministe
  Voir pnpm.io/motivation pour les détails
Avec les scripts UV, il a été possible de déployer un client/serveur MCP dans un seul fichier
Article lié : MCP server in a file
La plupart des scripts tiennent dans un seul fichier, donc ajouter le code ci-dessous en haut simplifie énormément la vie
#!/usr/bin/env -S uv run --script
Le script se comporte alors comme un exécutable autonome, et uv installe automatiquement les modules nécessaires
- Du point de vue de la sécurité, cette approche comporte quand même des risques
  L’auteur du script peut dissimuler des dépendances malveillantes
  Une fonction de liste blanche serait utile
- À la date du jour, on peut utiliser un flag de date de publication maximale pour figer les versions sans lockfile
  En revanche, certains paquets ne permettent pas de détecter leur date de publication (par ex. yaml)
- Il faut avoir uv installé pour l’exécuter, donc ce n’est pas totalement standalone
- Il faut que /usr/bin/env -S soit pris en charge, et les noms de dépendances doivent être les noms des paquets distribués utilisés par la commande uv pip install
  C’est le standard PEP 723 et pipx le prend aussi en charge
- Une connexion Internet est nécessaire, et selon l’état du dépôt, des versions différentes peuvent être installées
Avant d’utiliser uv, je ne m’intéressais pas à Rust, mais grâce à uv je migre maintenant le code sensible aux performances vers Rust
J’aimerais que conda disparaisse complètement. Sur les clusters ML, les environnements conda deviennent énormes et la reproductibilité est mauvaise
- On m’a recommandé pixi, une alternative à conda basée sur Rust. Elle réutilise le solveur PyPI de uv
- Avec conda, si on fige les dépendances, on obtient de la reproductibilité, mais les builds sont lents
- Pour un cluster ML, je pense qu’avec la conteneurisation, conda devient inutile
- Je me demande comment uv gère les dépendances CUDA
- Pour une approche open source de la gestion des grosses dépendances ML, voir la documentation Metaflow et le blog Fast Bakery
Avant, j’étais tout à fait satisfait du combo pyenv + venv + pip + pipx, mais uv
- est très rapide pour la résolution des dépendances
- offre une bien meilleure ergonomie avec uv run, uv add, etc.
- unifie plusieurs outils en un seul
- simplifie aussi l’installation de Python
Au lieu d’activer un environnement, il est bien plus pratique de mettre uv devant la commande
La gestion des versions de Python devient aussi plus simple, et on a une impression de batteries incluses par projet
Je ne sais pas encore ce que cela donnera sur le long terme en matière de stabilité, mais c’est devenu mon choix par défaut pour les nouveaux projets
- Activer un environnement, ce n’est au fond qu’ajuster le PATH et le prompt
  Certaines personnes n’aiment pas que uv détecte automatiquement l’environnement
  Je vois mal l’intérêt de la gestion des versions Python, mais avec uv recréer un environnement est bien plus rapide
- Ajouter uv permet d’exécuter des commandes de façon stateless, ce qui facilite la collaboration
- Je l’utilise avec mise pour l’activation automatique, mais le préfixe uv reste utile
- La philosophie de uv, c’est que les venv sont jetables. En cas de problème, il suffit de supprimer .venv
- En réalité, ce type de configuration d’environnement devrait simplement « marcher »
Cet article de blog correspond presque exactement à mon expérience
Il y a moins de friction et plus de simplicité
J’aimerais que la communauté Python adopte uv comme outil par défaut
Les outils basés sur Rust ont complètement transformé la vitesse de feedback
En revanche, je me demande comment Astral gagne de l’argent. Ils ont aussi levé des fonds, mais n’ont pas de produit payant
- Le modèle économique d’Astral consiste à vendre des logiciels d’entreprise intégrés à leurs outils open source
  Par exemple : un registre de paquets interne
  Interview liée : interview de Charlie Marsh
- Un produit qui pourrait évoluer vers un service payant est Pyx
- Conda gagne aussi de l’argent uniquement grâce à l’accès à des « paquets sécurisés »
  S’il y a 10 millions de développeurs Python, uv me semble tout à fait monétisable
Personnellement, je pense que les annotations de type et la suppression du GIL sont plus importantes que uv
uv en est encore à ses débuts et présente aussi des inconvénients. Au final, ce n’est qu’un gestionnaire de paquets de plus
- Une partie des éloges adressés à uv vient en fait des améliorations de pip et venv grâce à des PEP désormais standardisés
  Le nouveau resolver de pip et la hausse du nombre de distributions wheel ont joué un rôle important
  Article lié : Wheels are faster for pure Python
- Au niveau du langage, la suppression du GIL serait un changement plus important, mais il n’existe pas encore beaucoup de cas d’usage vraiment utiles
- Les type hints sont déjà une fonctionnalité ancienne, introduite en 2015
- uv n’est pas un simple gestionnaire de paquets, sa grande valeur est aussi dans la simplification du déploiement
  Le fait qu’il soit écrit en Rust est également intéressant. Comme LLVM, sa structure pourrait prendre en charge d’autres langages
  Du point de vue de l’utilisateur final, uv est bien meilleur, et si cela gêne les mainteneurs, il suffit de leur faire un retour
- Les annotations de type sont utiles pour la documentation, mais peu pratiques
  Un mode strict pourrait peut-être aussi améliorer les performances, mais cela entrerait en conflit avec la philosophie du langage
  Cela dit, si conda disparaissait, je serais prêt à passer à uv
Personnellement, je n’aime pas uv
- Il essaie d’en faire trop : remplacer à la fois pip, pyenv, virtualenv et même ruff
- Il faut utiliser uv pip, donc ce n’est même pas un remplacement complet
- La compatibilité avec Docker est aussi moins bonne
- Il y a beaucoup de nouvelles variables d’environnement, ce qui augmente la complexité
- Je ne trouve pas étrange que pyenv, virtualenv et pip soient séparés
  En revanche, pip et venv cassent souvent eux aussi, et c’est encore plus difficile à déboguer
- En réalité, pip, pyenv et virtualenv sont presque toujours utilisés ensemble, donc un outil unifié est logique
  uv ne remplace pas ruff
  Il n’y a même pas besoin de toucher aux variables d’environnement
- uv pip n’appelle pas pip : il fournit une interface compatible
  En pratique, c’est bien uv qui remplace pip
  Je me demande quels sont exactement les problèmes de compatibilité avec Docker
- En gérant avec uv add, uv sync, uv run, c’est beaucoup plus ergonomique et rapide
  Voir le concept de dépendances dans uv pour plus de détails
- D’après mon expérience, uv remplit bien ses différents rôles. Je serais curieux de savoir quels problèmes concrets ont été rencontrés

aer0700 2025-11-01

C’est vrai qu’uv est agréable à utiliser grâce à sa rapidité, mais je me demande aussi ce que ça aurait donné si l’on avait plutôt choisi d’améliorer pip.