- Depuis que la maintenance de Rye a été reprise par Astral en février 2024, uv, son resolver·installer sous-jacent, s’est rapidement amélioré et s’impose comme un candidat à l’unification des outils de packaging Python
- La dernière version de uv inclut désormais la manipulation de
pyproject.toml, le support des workspaces, les références à des packages locaux, l’installation de scripts et même la gestion de l’installation de Python, absorbant ainsi le périmètre autrefois couvert par Rye - L’essor des investissements dans l’IA et le ML a amené de nouveaux utilisateurs vers Python, mais la multiplicité des outils de packaging et leurs compatibilités inégales rendent l’expérience développeur encore peu cohérente
- L’écosystème du packaging a besoin d’un outil dominant utilisé par tous, afin que les investissements et la documentation convergent vers une seule stack, et Rye pourrait servir de chemin de migration vers un recentrage sur uv
- L’investissement en capital-risque dans Astral représente un risque que la PSF et les projets du cœur de Python doivent prendre en compte, mais uv est jugé comme un code qui, même dans le pire des cas, pourrait être forké et maintenu
La convergence des fonctionnalités de Rye vers uv
- En février 2024, la maintenance de Rye a été transférée à Astral, qui a ensuite rapidement amélioré les outils de packaging Python au cours des mois suivants
- Les utilisateurs de Rye ont pu constater que uv, le resolver·installer sous-jacent, devenait meilleur et plus rapide
- La dernière version de uv a commencé à fournir directement des fonctionnalités qui nécessitaient auparavant Rye
- manipulation du fichier
pyproject.toml - support des workspaces
- références à des packages locaux
- installation de scripts
- gestion de l’installation de Python
- manipulation du fichier
- Les utilisateurs actuels de Rye devraient examiner uv et donner leur retour à Astral
Pourquoi les outils de packaging Python doivent converger
- La présentation à EuroPython Prague porte sur la situation actuelle du packaging Python et sur les leçons tirées de la création de Rye
- L’objectif d’un outil de packaging est de devenir l’outil dominant dans son domaine
- l’outil utilisé par tout le monde doit être le meilleur outil
- car c’est lui que rencontrent les personnes qui découvrent Python au début de leur parcours en programmation
- Au cours des deux dernières années, Python est redevenu une plateforme extrêmement attractive et populaire pour les nouveaux développeurs, porté par les investissements et l’intérêt autour de l’IA et du ML
- Il est important que les nouveaux utilisateurs se souviennent de Python non pas comme d’un vieux langage mal outillé, mais comme d’un langage offrant une excellente expérience développeur
- Mais aujourd’hui, le packaging Python propose trop d’options, la compatibilité entre outils est incomplète et des incohérences persistantes dégradent l’expérience
- certains utilisateurs suivent un outil jusqu’à se heurter à une impasse, migrent alors toute leur stack vers conda, puis reviennent ensuite
Le potentiel de uv comme outil dominant
- Lorsqu’un outil occupe une position dominante, cela signifie que la majorité des investissements se concentre sur une seule stack
- Il serait souhaitable que Rye et les nombreux outils qui l’entourent n’aient plus besoin d’exister indépendamment une fois qu’un outil dominant est établi
- À l’heure actuelle, uv est considéré comme l’outil le mieux placé pour jouer ce rôle
- il ne couvre pas encore tous les cas d’usage
- mais il semble en voie d’y parvenir rapidement
- Le moment semble venu pour la communauté de commencer à se rassembler autour de uv
- Cela ne signifie pas que cet outil restera l’unique outil pour toujours
- les outils apparaissent et disparaissent
- un autre outil pourrait émerger à l’avenir
La mise à la retraite de Rye et l’évolution des recommandations pour les projets Python
- La dernière version attendue de Rye devrait retirer progressivement ses fonctionnalités propres, migrer les utilisateurs vers uv et se comporter, pour l’essentiel, comme un alias de uv
- Mais retirer Rye à lui seul ne suffira pas
- plusieurs solutions de gestion de packages sont encore utilisées dans l’écosystème Python
- la communauté doit orienter vers un plus petit nombre d’outils
- Rye et uv ont été construits sur de longues années d’évolution de l’écosystème sous-jacent
- le passage de
setup.pyaux eggs, puis aux wheels - le passage d’une absence de standards de métadonnées à un écosystème standardisé
- le passage de systèmes de build couplés à des systèmes de build séparés
- les travaux ayant rendu possibles des binaires Python redistribuables et téléchargeables
- l’écosystème des crates Rust et des bibliothèques Python associées
- le passage de
- La communauté doit se préparer à dire, un jour, qu’elle ne recommande plus certains outils
- autrefois, les guides destinés aux nouveaux développeurs recommandaient
ez_setup.pyeteasy_install - puis
ez_setup.pya été retiré de ces guides et remplacé parpip - certains projets ont recommandé
pip-tools,poetry,PDM - aujourd’hui, de nombreux projets affichent parfois cinq méthodes d’installation à cause de la diversité des outils
- autrefois, les guides destinés aux nouveaux développeurs recommandaient
- Les mainteneurs de projets Python importants devraient essayer eux-mêmes uv et déterminer s’ils peuvent le recommander à leurs utilisateurs
- L’article de Charlie chez Astral sur ce que uv peut faire aujourd’hui montre les progrès actuels de uv
L’investissement VC dans Astral et les risques pour la communauté
- Le fait qu’Astral, qui développe uv, soit une entreprise financée par du capital-risque est un sujet incontournable
- Du point de vue de la communauté, le fait qu’un acteur injecte beaucoup d’argent peut créer de nouveaux défis
- La PSF et les projets du cœur de Python doivent en tenir compte
- Au vu du code et du fonctionnement de uv, l’outil semble, même dans le pire des scénarios, pouvoir être forké et maintenu
- Même si Astral devait disparaître ou adopter des pratiques très douteuses sur le plan des licences, la communauté pourrait malgré tout se retrouver dans une meilleure situation qu’avant l’existence de uv
1 commentaires
Avis sur Hacker News
La dernière release d’uv a aussi été discutée hier : https://news.ycombinator.com/item?id=41302475
L’article lié est l’avis écrit par l’auteur de Rye après avoir vu cette release
Pour ceux que uv intéresse, le processus de release de Home Assistant a été fortement accéléré en remplaçant pip par uv
Le temps nécessaire à une release est passé d’environ 2,5 heures à environ 20 minutes, avec plus de détails ici : https://developers.home-assistant.io/blog/2024/04/03/build-i.... Pour info, je ne suis qu’un utilisateur de HA
J’utilise Python plutôt légèrement, mais je ne vois pas ce qu’il pouvait bien faire pour que cela prenne autant de temps, et ça me paraît absurde
Je sais que le packaging Python a des problèmes, mais personnellement je suis allé assez loin jusqu’ici avec plain pip
Le plus grand changement a été de passer de virtualenv au module venv intégré. Si je devais gérer les dépendances vraiment sérieusement, je pense que je ferais un monorepo façon FAANG pour éviter les tracas liés aux gestionnaires de paquets
Je gère un monorepo Python en production et la gestion des dépendances est infernale. J’essaie d’appliquer quelques nouvelles fonctionnalités de Poetry, mais l’état de l’écosystème autour des gros monorepos est catastrophique
L’objectif n’est pas « ça me suffit », mais de disposer d’outils standard pour les paquets et les environnements virtuels qui s’étendent depuis une organisation de 2 développeurs Python jusqu’à des centaines ou des milliers de personnes. Sinon l’écosystème se fragmente, les bugs et la documentation difficile se multiplient, et le langage a du mal à continuer d’évoluer efficacement
Mais il n’y a aucun moyen de définir pour quelle version de Python un projet a été conçu. Si l’on crée un paquet, il faudra probablement le tester sur plusieurs versions ; et si ce n’est pas un paquet distribuable installable, mais un ensemble de code partagé par quelques développeurs, pour des tâches comme exécuter des modèles de machine learning, déployer des cloud functions ou générer des rapports, on voudra généralement cibler précisément une seule version de Python
Je me demande aussi si l’approche monorepo signifie copier numpy et pandas dans le dépôt
Au début, j’espérais qu’un nouvel outil résoudrait le problème du « packaging » de Python, mais en lisant davantage, j’ai compris qu’il s’agissait plutôt de gestion de paquets que du problème consistant à emballer les applications Python que je crée
Personnellement, je n’ai pas eu de gros problèmes avec la gestion des paquets Python ; même si l’écosystème a des lacunes, à part des choses comme l’absence de namespaces, pip fonctionne globalement bien
Ce qui est vraiment agaçant, c’est qu’il n’est pas facile d’envelopper une application Python dans un exécutable pour la déployer quelque part. En production, je vois souvent des git clone suivis de la création d’un virtualenv ; cela impose au serveur cible plus de connectivité que nécessaire et laisse parfois des dépendances de développement dans le système d’exploitation. Du point de vue de la sécurité, c’est une très mauvaise idée, donc tant que ce problème ne sera pas résolu, je préférerai d’autres langages pour les tâches qui nécessitent une distribution aux utilisateurs finaux ou un déploiement en production
Pour cela, l’application doit être livrée à l’utilisateur, y trouver Python, et tout ce processus doit être transparent pour lui. C’est l’une des raisons pour lesquelles, en créant Rye — et il en va de même pour uv —, on a voulu prendre en charge l’installation de Python d’une manière qui ne casse pas le système
La forme plus avancée consisterait à automatiser tout le processus, uv compris. Même aujourd’hui, si on le souhaite, on peut utiliser un installateur curl to bash pour installer uv/Rye et l’application dans un emplacement temporaire dédié à l’app, sans jamais casser le système de l’utilisateur
J’aimerais qu’un jour ce processus devienne totalement transparent, sans besoin d’accès réseau, et qu’il propose aussi des choses comme un .msi pour Windows. Mais cela suppose qu’un outil comme uv puisse placer arbitrairement un Python précompilé et toutes les dépendances nécessaires à l’endroit adapté à la plateforme de l’utilisateur
Le bonus final qu’uv pourrait fournir un jour serait un artefact entièrement packagé, et ce serait excellent. Même l’étape précédente pourrait déjà rendre beaucoup moins pénible l’expérience consistant à fournir aux utilisateurs des outils en ligne de commande écrits en Python. On peut utiliser uvx, ou même masquer complètement uv si on le souhaite
Par exemple, il existe des outils qui créent des installateurs par système d’exploitation, et des outils sont aussi apparus pour déployer vers des cibles particulières comme Android, iOS ou le navigateur. Bien sûr, un paquet donné peut ne pas fonctionner sur une cible donnée, mais comme il existe une interface standard, si le code peut s’exécuter quelque part, l’outil destiné à cette cible devrait pouvoir produire un résultat qui y fonctionne
Depuis le rug pull de npm financé par du capital-risque, son rachat par Microsoft, et après qu’OpenAI a montré que même le statut juridique d’organisme à but non lucratif n’était qu’un marketing sans poids pour des dirigeants impliqués dans des trajectoires de financement par capital-risque, j’hésite à confier à ce type d’organisations une infrastructure de langage située sur le chemin critique.
Les personnes qui y contribuent sont chacune excellentes, et souvent brillantes, mais les intérêts financiers au niveau de l’organisation sont viciés dès le départ. Au bout de 1 à 4 ans, ce qui compte, c’est l’organisation. C’est du genre « on meurt en héros, ou on vit assez longtemps pour devenir le méchant ».
Donc des linters rapides, de la vérification de types, du scan de code, des assistants de PR, très bien : on peut toujours les remplacer. Mais pas le flux d’installation ni les dépôts de paquets.
C’est regrettable quand on pense à l’état de pip et conda, mais c’est la réalité, à mon avis.
Je pense que Microsoft possède Python, même si ce n’est pas affiché publiquement.
Il y a quelques années, je voulais créer des bindings Python pour kubectl, et j’ai découvert que, pour que cela fonctionne en multiplateforme, CGo devait utiliser le même compilateur que Python sur toutes les plateformes. Or, sous Windows, CGO utilise MINGW tandis que Python utilise MSVC. J’ai demandé sur la liste de diffusion de développement Python qui existait à l’époque pourquoi un projet « open source » utilisait un compilateur propriétaire, et la réponse a été que MSVC était un choix historique et qu’il était désormais impossible d’en changer. L’explication était que Microsoft fournissait à la Python Foundation une infrastructure gratuite pour faire tourner la CI et les builds, ainsi que des développeurs travaillant sur l’interpréteur Python. Autrement dit, des employés de Microsoft sont payés par Microsoft pour travailler sur l’interpréteur Python, avec pour consigne de ne pas retirer les outils Microsoft de la chaîne d’outillage.
Année après année, la situation a empiré. Comme dans des projets similaires, le succès a créé un terrain propice à la prise de pouvoir par des gens sans compétence particulière, et la Python Foundation ainsi que des projets périphériques comme la PyPA ont commencé à se remplir de personnes arrivées là non pas en contribuant du code utile, mais en rédigeant des pages de code de conduite. Les querelles interminables autour de ce code de conduite et du contrôle des postes ont fini par pousser dehors, ou faire bannir, d’anciens contributeurs ; récemment, Tim, le créateur de Tim sort, a même été banni.
Microsoft continue de pousser l’agenda habituel qu’il applique à tous les projets qu’il touche : ajouter une foule de fonctionnalités inutiles pour la publicité, faire partir le projet dans tous les sens, et surtout le faire coller autant que possible aux modes du moment. Ainsi, même si Python est un langage avec un système de types totalement différent, on y ajoute autant que possible des types façon machine learning ; et même si c’est un langage utilisé pour moitié à attacher dynamiquement des bibliothèques natives, on s’acharne sur la précompilation et le JIT. En substance, on est en train d’en faire du C# sans accolades.
Microsoft est assez malin pour savoir que, s’il annonçait publiquement posséder Python, beaucoup de gens s’éloigneraient de la technologie, donc il ne le met pas trop en avant. Mais il continue de rendre les développeurs dépendants de ses outils, et un jour il viendra récupérer son investissement.
Mais jusqu’ici, ce qu’elles ont produit, ce sont essentiellement des milliards de billets de blog de contributeurs disant : « le système que nous avons créé nous empêche d’être utiles, et de toute façon ce n’est pas notre faute ».
Elles semblent tellement absorbées par leurs systèmes internes et leur politique interne qu’elles ne savent même plus pourquoi elles sont là.
Donc si quelqu’un parvient réellement à faire du bon travail et à prendre le marché, comme Astral, c’est précisément le résultat que nous, la communauté, méritons.
[1] : je parle ici de politique interne. Pas d’une crise bizarre d’extrême droite du genre « recrutements DEI ! »
Ces outils ont encore un problème d’autorité.
Ce n’est pas validé par la PyPA, ce qui le différencie de cargo. En même temps, la PyPA n’a pas fourni de solution globale depuis des années, tandis que le packaging Python et les outils de développement continuaient de se multiplier. Il y a à peine 3 ou 4 ans, poetry et pipenv semblaient résoudre les problèmes de packaging Python que pip+virtualenv ne réglaient pas.
Je pense maintenant que la PyPA devrait monter à bord du navire astral.sh, mais je ne sais pas si elle le ferait sans un certain niveau de contrôle.
À mes yeux, c’était en grande partie dû à des relations personnelles, et Pipenv était alors catastrophique. L’intention était bonne, mais en entreprise, même sur des dépôts avec relativement peu de dépendances largement utilisées, il fallait attendre une heure pour mettre à jour le fichier de verrouillage. Ça ne fonctionnait tout simplement pas.
En pratique, je suis très reconnaissant pour le travail technique difficile que fait la PyPA. Mais je me soucie assez peu de l’ensemble d’outils qu’elle recommande aujourd’hui. Je pense qu’il vaut mieux utiliser ce que la communauté utilise et ne pas trop se préoccuper des propositions « officielles ».
Le nombre de participants n’est pas clair, et on ne sait pas vraiment dans quelle mesure la PyPA est liée au cœur de Python ou à la PSF.
L’approbation qui serait réellement utile viendrait, selon moi, du projet Python central lui-même. Dans un monde idéal, le tutoriel officiel de Python commencerait par « voici comment installer Python » en guidant d’abord l’installation de uv, de la même manière que la documentation officielle de Rust renvoie vers rustup et cargo.
J’espère vivement que la PSF construira avec Astral une relation permettant qu’une telle réalité devienne un jour possible.
Dans ce contexte, elle a largement prouvé elle-même qu’elle était sans pertinence. Tout ce qu’elle touche semble pourrir, donc, même si c’est regrettable, j’aimerais qu’elle reste loin de ce problème. Cela me fait mal de le dire et va à l’encontre de ma philosophie, mais c’est simplement un jugement qui reflète l’état actuel des choses. J’ai travaillé à plein temps en Python pendant 10 ans, et les autres écosystèmes de packaging ont pratiquement pris plus d’un tour d’avance sur Python.
Je ne me soucie même plus des nuances du type « est-ce un problème d’exécution de la PyPA, ou bien le périmètre de rôle qui lui a été défini est-il mauvais ? ». J’en ai assez d’être entraîné dans ce genre de discussions.
Armin défend l’idée que uv domine ce domaine, mais reconnaît aussi que, comme il est financé par du capital-risque, il pourrait y avoir un rug pull
Comme solution à ce problème potentiel, il dit qu’il est « très facile à forker » ; mais un fork ne crée-t-il pas, par nature, davantage de fragmentation ? C’est précisément le problème qu’il veut résoudre
À mon avis, un outil qui ambitionne de dominer l’écosystème du packaging Python devrait être porté et contrôlé par la communauté
Le niveau de fragmentation après une première unification autour d’un outil ayant subi un rug pull pourrait être bien plus faible qu’avant l’unification
Et cette communauté imaginaire a-t-elle encore besoin de plusieurs décennies pour créer un excellent outil dominant ?
Ce matin, au travail, j’ai regardé comment migrer notre logiciel de Poetry vers uv à cause de la lenteur de Poetry
Pour l’instant, je lis beaucoup de documentation, mais je n’avance pas vraiment. J’avais aussi fait la migration vers Poetry auparavant, et c’était beaucoup plus simple. D’après ce que j’ai vu jusqu’ici, Poetry essayait de faire un gestionnaire de paquets simple, qui se comporte comme les autres gestionnaires de paquets, tandis qu’uv semble conserver une bonne partie de la folie des paquets Python
Il n’y a pas non plus de petits changements dans Poetry qui cassent le format package.toml, ni de « sources » idiotes qui ne fonctionnent pas pour les dépendances transitives et allongent le temps de résolution sur plusieurs index
uv donne vraiment l’impression de s’intégrer directement au flux d’outils Python standard
Je ne blâmerais pas les gens s’ils passaient leur tour cette fois-ci et attendaient l’édition 2026 de « Gestionnaire de paquets Python : cette fois, on a vraiment réglé le problème ! »
Cela dit, je reste un utilisateur satisfait de Nix
J’aime beaucoup cette façon de présenter les choses
Grâce au travail accumulé progressivement par beaucoup de personnes pendant longtemps, on en est arrivé au point où quelques personnes dans une entreprise peuvent désormais améliorer radicalement la situation avec un effort modéré