uv, le gestionnaire de paquets et de projets Python ultra-rapide écrit en Rust

• uv est un outil de gestion de paquets et de projets Python extrêmement rapide, basé sur Rust
• Il peut remplacer à lui seul pip, pip-tools, pipx, poetry, pyenv, virtualenv, etc.
• Il offre des performances jusqu’à 10 à 100 fois supérieures, une économie d’espace disque, un cache robuste et un support cross-platform
• Il inclut un environnement de développement intégré pour la gestion des scripts, des projets, des outils et de multiples versions de Python
• Il permet de mettre en place un workflow moderne de développement Python, optimisé pour la productivité, les projets de grande taille et les itérations rapides

---

Présentation de l’open source et points de différenciation

• uv regroupe dans un seul outil les fonctions de plusieurs gestionnaires Python existants comme pip, pip-tools, pipx, poetry, pyenv, virtualenv, twine
• Développé en Rust, il offre des performances remarquables, avec des vitesses d’installation et de synchronisation 10 à 100 fois plus rapides que pip traditionnel
• Grâce à un cache global et à la déduplication des dépendances, il permet une optimisation de l’usage du disque, tout en proposant une CLI intuitive et une compatibilité familière avec pip
• Il peut être installé comme exécutable autonome sur macOS, Linux et Windows
• Son installation autonome, son intégration avec pip et pipx, ainsi que sa mise à jour automatique native en font un outil particulièrement pratique

Principales caractéristiques (Highlights)

• Un seul outil, uv, permet de remplacer de nombreuses fonctions de pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv, etc.
• Il fournit des performances d’installation / mise à jour / synchronisation 10 à 100 fois plus rapides que pip
• Il prend en charge la gestion des dépendances de projet sur la base de lockfiles, ainsi que les workspaces et un universal lockfile
• Il permet la déclaration inline des dépendances de scripts et l’exécution avec isolement automatique de l’environnement
• Il prend en charge l’installation, la gestion et le changement de multiples versions de Python
• Il permet d’exécuter et d’installer des outils distribués sous forme de paquets Python (en remplacement de pipx)
• Il est compatible avec l’interface pip et ajoute des fonctions avancées (override de versions, résolution indépendante de la plateforme, etc.)
• Son workspace de style Cargo est optimisé pour les projets de grande taille
• Son cache global réduit au minimum la duplication des dépendances et améliore l’efficacité de l’espace disque
• Il peut être installé et utilisé via curl, pip ou pipx, sans environnement Rust/Python préalable
• Il prend en charge plusieurs plateformes, notamment macOS, Linux et Windows
• Il est développé par l’équipe à l’origine d’Astral et de Ruff

Gestion de projet (Project Management)

• Il prend entièrement en charge, au niveau du projet, les dépendances, environnements, fichiers de verrouillage (lock) et workspaces
• La commande uv init initialise automatiquement un projet et crée un virtualenv
• uv add permet d’ajouter des dépendances, tandis que uv lock et uv sync automatisent la synchronisation des paquets et les audits de sécurité
• Il remplace les fonctionnalités d’outils modernes de gestion de projet Python comme Poetry ou Rye, tout en garantissant des performances de traitement supérieures
• Il prend aussi en charge le build et la publication (publish) de projets qui ne sont pas gérés par uv

Gestion des scripts (Scripts)

• Il permet de déclarer des métadonnées de dépendances inline dans un script mono-fichier
• Lors de l’exécution d’un script, il prend en charge l’isolement automatique du virtualenv et l’installation des dépendances
• uv add --script permet de gérer les dépendances par script, et la commande uv run exécute le script dans un environnement isolé
• Il est particulièrement adapté aux scripts ponctuels, comme en data science ou en automatisation

Gestion des outils (Tools)

• Il permet d’installer et d’exécuter des outils CLI empaquetés en Python, à la manière de pipx
• Les commandes uv tool install et uvx permettent une exécution temporaire ou globale
• Il prend en charge l’inspection des outils installés, la gestion des versions et les mises à jour

Gestion des versions de Python

• Il permet d’installer facilement plusieurs versions de Python et de basculer instantanément entre elles
• Il permet de gérer plusieurs versions en parallèle et de définir un pin .python-version par projet
• Des implémentations alternatives comme pypy sont également prises en charge via la même interface
• Les commandes uv python install/pin permettent d’installer, de sélectionner et d’activer une version

Interface pip (Pip Interface)

• Avec uv pip et uv venv, il remplace entièrement pip, pip-tools et virtualenv
• Il inclut des fonctions avancées comme l’override des versions de dépendances, la résolution indépendante de la plateforme et les builds reproductibles
• Il agit comme un remplaçant drop-in de pip sans changer les workflows existants, tout en apportant un gain de performances de 10 à 100 fois
• Il prend en charge la conversion requirements.in → requirements.txt, la création de virtualenvs et la synchronisation des requirements

Plateformes et politique de versions

• Il prend en charge divers systèmes d’exploitation : Windows, macOS et Linux
• Les informations sur la politique et les plateformes supportées sont disponibles dans la documentation officielle

Contribution (Contributing)

• Le projet vise à accueillir des contributeurs de tous niveaux, du débutant à l’expert, et fournit des guides dédiés

FAQ

• uv se prononce « u-v »
• Le style est fixé en minuscules : uv

Contexte technique et remerciements (Acknowledgements)

• L’algorithme de résolution des dépendances utilise PubGrub
• L’implémentation Git repose sur Cargo
• La stratégie d’optimisation s’inspire largement d’outils modernes de packaging comme pnpm, Orogene, Bun, Posy

Licence

• Utilisable au choix sous MIT ou Apache-2.0
• Le code contribué est également proposé sous la même double licence

[GN⁺]

Avis Hacker News

• Il y a encore quelques mois, je pensais que je n’utiliserais jamais uv, parce que j’étais déjà habitué à venv et pip et que je ne voyais pas l’intérêt d’un autre outil. Mais récemment, sur un serveur partagé sans accès root, toutes sortes de paquets et de drivers étaient cassés et j’avais besoin de pytorch ; cette expérience m’a fait basculer complètement vers uv. Avec pip, tout prenait longtemps, le cache occupait énormément d’espace et il était difficile à déplacer. En passant à uv, tout a tellement bien fonctionné que j’en suis ravi. Si vous hésitez encore, essayez-le au moins 5 minutes

  • Le plus gros avantage de uv, c’est sa compatibilité totale avec le workflow existant basé sur venv : il suffit d’exécuter uv venv
  • uv me semble aussi bien plus simple à expliquer, surtout pour guider des débutants. La combinaison pip + fichier de configuration + venv prêtait à confusion : il fallait créer le bon venv, installer correctement, se souvenir d’un shebang un peu bancal ou de l’activation du venv à chaque exécution/test de script, et les messages d’erreur n’aidaient pas toujours vraiment. Quand j’enseignais ça à des débutants, ces outils me paraissaient vraiment pénibles. Maintenant, il suffit de retenir "uv run", "uv add" et "uv sync", donc l’équipe l’adopte avec beaucoup moins d’appréhension
  • De mon côté, je suis passé de asdf à mise, et je me demande comment ça se compare à des outils généralistes comme uv
  • Tu disais que le cache pip prenait beaucoup de place et qu’on ne pouvait pas vraiment changer son emplacement ; je me demande si uv est meilleur sur l’usage de l’espace disque du dépôt, et si oui, si c’est grâce à un meilleur partage
  • J’ai récemment essayé ça dans un dépôt expérimental après avoir vu un petit guide qui commençait par "uv a b c". Il semble y avoir pas mal de duplication en interne, mais en usage réel, sur un hôte GNU-Debian-Ubuntu standard, je n’ai eu aucun problème et tout s’est déroulé sans accroc

• La première fois que j’ai utilisé uv, c’était tellement rapide par rapport à pip que j’ai cru qu’il y avait eu une erreur ou que ça n’avait pas vraiment marché

  • Parfois, l’installation d’un paquet prend autour de 200 ms, donc on sent juste un tout petit délai entre l’appui sur Entrée et le retour du prompt. Avec Poetry, en revanche, on a le temps d’aller se faire un café, donc la différence de vitesse saute aux yeux
  • J’ai eu exactement la même impression. C’est tellement fluide qu’on a l’impression que ce n’est pas du Python
  • J’ai vécu quelque chose de similaire récemment, et ça m’a fait adopter uv définitivement
  • Moi aussi, j’étais presque méfiant, mais après avoir essayé, impossible de revenir en arrière

• Je pense que uv et ruff sont de superbes contre-exemples à l’idée qu’il ne faut « jamais réinventer la roue ». Quand l’objectif est clair, on peut parfois produire quelque chose de très largement supérieur à l’existant

  • À mon avis, cette phrase s’applique surtout comme conseil destiné aux débutants qui ne connaissent pas encore bien l’existant ; autrement dit, elle n’est vraie que quand quelqu’un tente une réinvention sans comprendre les limites ni les points d’amélioration du système. Pour de vrais experts, ça ne s’applique pas
  • Ils n’ont pas réinventé la roue ; ils ont remplacé une roue en bois existante par un matériau plus solide capable de tourner 10 fois plus vite
  • Rien qu’en regardant l’histoire de la gestion des paquets Python, on a l’impression que tout le monde se lance en pensant pouvoir faire mieux que l’existant
  • En réalité, le proverbe « ne pas réinventer la roue » n’a pas beaucoup de sens : même les vraies roues ont continué à évoluer, et il n’y a aucune raison que le logiciel ne puisse pas lui aussi fabriquer de meilleures roues
  • Hors sujet, mais je me demande pourquoi certains préfèrent l’expression longue "order of magnitude better" au lieu de simplement dire "10x"

• Sur les petites machines ou les systèmes peu puissants (comme Windows sur une AWS T2.micro), uv tente trop de téléchargements simultanés et provoque des timeouts. Le problème se résout en limitant le nombre de téléchargements concurrents à 1 ou 2 avec la variable d’environnement UV_CONCURRENT_DOWNLOADS. Je trouve le réglage par défaut de uv trop agressif ; ce serait bien qu’il s’améliore en ajustant automatiquement selon le serveur, par exemple en se basant sur la vitesse de téléchargement

  • Ce n’est pas du tout un cas étrange ; beaucoup de gens font tourner des side projects sur des VPS bon marché. Moi aussi, souvent — même si ce n’est pas sur AWS. Merci pour le partage, et j’espère que la détection automatique sera améliorée

• J’essaie uv récemment sur mon portable à titre personnel, et comme j’étais habitué à pip, la vitesse perçue me paraît tellement invraisemblable que plusieurs fois je me suis demandé si ça s’était bien exécuté

• J’adore la commande uv add <mydependencies> --script mycoolscript.py, et avec #!/usr/bin/env -S uv run tout en haut, on peut exécuter immédiatement un script Python, donc c’est devenu un outil extrêmement utile pour moi

  • J’ai même appris cette méthode à Claude Project via un prompt spécialisé, ce qui permet de générer automatiquement un script complet avec dépendances à partir d’une seule entrée. La date de cutoff de Claude 4 est mars 2025, et avec Claude Sonnet 4, ça fonctionne même sans prompt supplémentaire. Par exemple, si on donne une URL, il génère directement du code qui fait du crawling avec httpx et beautifulsoup puis renvoie une liste de liens en CSV ressource liée résultat du script Claude
  • J’utilise cette astuce avec le app-mode des notebooks Marimo.io. Tant que uv est installé, on peut transmettre à quelqu’un très facilement une app réactive et reproductible, créée à la volée avec un minimum de préparation. Franchement, c’est une combinaison parfaite
  • Maintenant, j’ai pris l’habitude d’exécuter à l’improviste même de petits scripts. Comme je n’ai plus à me soucier de l’environnement ni de la gestion des dépendances, c’est beaucoup plus agréable. article sur the little scripter, vidéo YouTube liée, ez-mcp sur GitHub
  • Correction : j’avais mal lu l’exemple. En contexte de projet, uv add --script et un simple uv add sont différents. Et il y a bien d’autres fonctions utiles dans la documentation officielle, comme run --with ou le support de PEP723, donc je recommande d’y jeter un œil guide officiel
  • Question : qu’est-ce que "mydependencies" exactement ? Est-ce que ça désigne un fichier de configuration ?

• J’avais essayé uv il y a quelque temps et j’ai été surpris par sa vitesse écrasante et sa simplicité d’utilisation. À ce stade, il n’y a quasiment plus de raison d’utiliser pip, et si on ne fait que du Python, on n’a même plus besoin de conda

  • Je n’utilise plus non plus pyenv ni poetry

• J’adore vraiment UV. J’aime aussi Ruff de l’équipe Astral, au point d’avoir remplacé entièrement pylint + Black par Ruff pour le linting et le formatage. Dans mon cas, le temps de lint est passé de 90 secondes à moins de 1,5 seconde, ce qui m’a sidéré

  • En revanche, j’ai découvert plus tard que ruff ne couvre qu’une partie des vérifications de pylint et laisse aussi passer des erreurs pourtant très évidentes, y compris du code qui ne peut même pas s’exécuter

• Récemment, j’aime beaucoup utiliser le motif suivant pour exécuter de petits scripts autonomes

  #!/usr/bin/env -S uv --quiet run --script
  # /// script
  # requires-python = ">=3.13"
  # dependencies = [
  #   "python-dateutil",
  # ]
  # ///
  #
  # [python script that needs dateutil]  
  

  • La ligne shebang est vraiment trop difficile à mémoriser ; j’aimerais qu’il existe une forme plus simple, comme #!/usr/bin/env uvx, parce qu’aujourd’hui je dois la rechercher à chaque fois

• J’en suis totalement satisfait et je n’ai aucune envie de revenir à pip/twine/requirements.txt. Plusieurs projets stockaient des wheels partagées sur un GitLab interne, et les 10 lignes de YAML d’avant peuvent maintenant être remplacées par deux lignes : "uv build" et "uv publish". C’est pratique pour récupérer les dépendances et voir d’un coup d’œil les dépendances principales, sans avoir tout mélanger dans un requirements.txt