Uv - Outil de packaging Python ultra-rapide implémenté en Rust

• uv est un installateur et résolveur de paquets Python ultra-rapide écrit en Rust, conçu pour remplacer les workflows pip et pip-tools
• uv constitue une étape vers un « Cargo for Python » : un gestionnaire complet de projets et de paquets Python, rapide, fiable et facile à utiliser
• Il est prévu de reprendre la gestion de Rye, l’outil de packaging Python développé de façon expérimentale par Armin Ronacher, et d’étendre uv comme projet successeur unifié

Une focalisation obsessionnelle sur les performances

• uv est 8 à 10 fois plus rapide que pip et pip-tools sans cache, et 80 à 115 fois plus rapide avec cache.
• Il utilise un cache global des modules pour éviter de retélécharger ou reconstruire les dépendances, et exploite le Copy-on-Write ainsi que les liens physiques sur les systèmes de fichiers pris en charge afin de minimiser l’utilisation de l’espace disque.

Optimisé pour l’adoption

• La version initiale de uv prend en charge les API de pip et pip-tools, et peut être utilisée dans des projets existants sans modification de configuration.
• uv est distribué sous la forme d’un unique binaire statique et peut remplacer pip, pip-tools et virtualenv.
• Il peut être installé séparément de Python lui-même, sans avoir à gérer l’installation de pip selon la version de Python.

« Cargo for Python » : uv et Rye

• uv est une étape intermédiaire vers un gestionnaire unifié de paquets et de projets Python, rapide, fiable et simple à utiliser.
• uv vise à devenir un binaire unique englobant non seulement pip, pip-tools et virtualenv, mais aussi pipx, tox, poetry, pyenv, ruff et d’autres outils.

API compatibles

• À la place de pip install, vous pouvez utiliser uv pip install pour installer des dépendances Python depuis la ligne de commande, un fichier de requirements ou pyproject.toml.
• À la place de pip-compile, vous pouvez utiliser uv pip compile pour générer un requirements.txt verrouillé.
• À la place de pip-sync, vous pouvez utiliser uv pip sync pour synchroniser un requirements.txt verrouillé et un environnement virtuel.

Feuille de route

• Après cette version, le plan est de donner la priorité au support des utilisateurs tout en se concentrant sur l’amélioration de la compatibilité, des performances et de la stabilité.
• Ensuite, l’objectif est d’étendre uv pour en faire un gestionnaire complet de projets et de paquets Python.

Remerciements

• Des remerciements sont adressés à toutes les personnes ayant contribué directement ou indirectement au développement de uv.
• En particulier, merci à Jacob Finkelman et Matthieu Pizenberg, dont le solveur de versions de base PubGrub est utilisé dans uv.

L’avis de GN⁺

• uv est un outil innovant qui offre aux développeurs Python des performances bien supérieures à celles de pip, ce qui peut réduire considérablement le temps de configuration des projets.
• Écrit en Rust, il reflète une nouvelle tendance de l’écosystème Python mettant l’accent sur les performances et la stabilité, avec une amélioration attendue notable de l’expérience développeur.
• Le développement de uv vise à unifier les outils de packaging et de gestion de projets Python, ce qui devrait permettre aux développeurs de travailler de manière plus efficace et plus cohérente.

[kyunghoon]

La vitesse est vraiment impressionnante ;;

[ajh508]

J’espère qu’il pourra s’étendre au point de remplacer conda.

[GN⁺]

Avis Hacker News

• Doutes sur un pip-and-more soutenu par du capital-risque

  • Il est difficile de comprendre comment un pip-and-more financé par du capital-risque générera des revenus une fois que la machine à imprimer de l’argent gratuit tombera en panne.

• Question sur l’absence de prise en charge par uv de la génération de lockfiles indépendants de la plateforme

  • Contrairement à Poetry ou PDM, uv ne génère pas de lockfiles indépendants de la plateforme ; cette approche semble dépendre des fichiers de requirements et ne paraît pas cohérente avec l’objectif d’être le « Cargo de Python ».

• Évaluation positive de la prise en charge par uv de stratégies alternatives de résolution des dépendances

  • uv suit par défaut la stratégie standard de résolution des dépendances Python, qui privilégie les versions de paquets compatibles les plus récentes, mais offre aussi la possibilité de tester avec les versions compatibles les plus basses via l’option --resolution=lowest.
  • Le fait qu’uv permette, via le paramètre --python-version, de générer une résolution pour une version de Python différente de celle actuellement installée est excellent.

• Interrogation sur la complexité du système de paquets Python

  • On s’interroge sur la façon dont on en est arrivé à une histoire de packaging aussi complexe, alors que la philosophie de l’interpréteur Python inclut le principe selon lequel « il devrait y avoir une seule manière évidente de faire les choses ».

• Aspect intéressant de l’utilisation de pubgrub-rs par uv

  • Le fait qu’uv utilise pubgrub-rs, une implémentation en Rust de l’algorithme de résolution de versions pubgrub initialement écrit pour le langage Dart, est jugé intéressant ; il est amusant de voir cette chaîne d’inspiration se poursuivre entre langages.

• Mention d’une prédiction sur la trajectoire de l’équipe Astral

  • Il est mentionné qu’une prédiction avait été faite il y a 11 jours selon laquelle l’équipe Astral étendrait les fonctionnalités de ruff jusqu’à couvrir tout ce dont les développeurs Python ont besoin.

• Expérience personnelle sur la vitesse de pip

  • pip fonctionne généralement vite, mais devient lent lorsqu’il faut télécharger beaucoup de données ou compiler des bibliothèques natives. En revanche, conda est très lent, même sur des machines puissantes.

• Point de vue sceptique sur un nouveau gestionnaire de paquets Python

  • Encore un autre gestionnaire de paquets Python apparaît, mais s’il peut remplacer pip, il sera possible de migrer comme on l’a fait vers ruff pour gagner en vitesse. Il faut une solution durable au packaging Python.

• Curiosité à propos du choix d’uv de générer des fichiers requirements.txt spécifiques à la plateforme

  • On se demande pourquoi uv a choisi de générer des fichiers requirements.txt spécifiques à la plateforme plutôt que des fichiers poetry.lock et pdm.lock indépendants de la plateforme.

• Félicitations et réaction positive au travail de l’équipe Astral

  • Des inquiétudes avaient été exprimées à propos d’une tentative externe de « corriger » le packaging Python, mais il est réjouissant de voir que la compatibilité est prioritaire. Les efforts de l’équipe Astral pour mettre l’accent sur la compatibilité avec les outils et standards existants sont salués.

• Question sur les problèmes de compilation de certains paquets pip

  • Certains paquets pip exigent une compilation dépendant d’une chaîne d’outils complète, comme gcc, g++, gtk ou Qt ; la question est de savoir comment cela pourrait être rendu moins sujet aux erreurs et plus convivial pour les utilisateurs.