PYX : la prochaine étape du packaging Python
(astral.sh)- pyx est un registre de paquets natif pour Python créé par l’équipe de développement de uv, qui accélère jusqu’à 10 fois l’installation depuis PyPI, PyTorch et des sources privées
- Au-delà du périmètre des registres de paquets traditionnels, il offre des fonctions de vitesse, sécurité et détection GPU, et prend en charge à la fois les paquets internes et les sources publiques comme PyPI et PyTorch
- Il fournit des URL d’index dédiées permettant de filtrer selon des critères comme la popularité d’un paquet, sa date de création ou la présence de vulnérabilités, afin de renforcer la sécurité et la conformité
- Grâce à la prise en charge des standards les plus récents propres à Python et à son intégration directe avec uv, l’authentification et l’utilisation sont possibles sans configuration
- Il résout, via une intégration serveur-client, les principaux problèmes des environnements d’entreprise comme les builds redondants au sein des équipes, la difficulté d’installation de PyTorch et CUDA, les builds cassés ou les contraintes d’authentification
- Grâce à sa détection GPU, il fournit des versions précompilées de PyTorch, vLLM, FlashAttention et DeepSpeed adaptées au matériel, avec des métadonnées cohérentes et une configuration optimale
- Il offre des performances nettement supérieures aux autres registres privés grâce à des artefacts optimisés et à l’API de métadonnées native de uv
Vision et contexte d’Astral
- Astral est une entreprise qui développe des outils de développement haute performance pour l’écosystème Python, notamment connue pour Ruff (linter et formateur) et uv (gestionnaire de paquets)
- L’entreprise est née du constat que, bien que Python soit le langage de programmation le plus populaire au monde, il manque encore d’un support suffisant côté tooling
- Aujourd’hui, la chaîne d’outils d’Astral dépasse les 100 millions d’installations par mois, et uv traite plus de 500 millions de requêtes par jour, avec une croissance explosive
- L’objectif est de faire de Python l’écosystème de programmation le plus productif, et pour cela Astral veut aller au-delà des outils clients en construisant un cloud Python
Présentation de pyx
- pyx est un registre de paquets natif pour Python conçu comme le backend optimisé de uv
- Hébergement possible de paquets internes
- Rôle de frontend accéléré et configurable pour des sources publiques comme PyPI ou l’index PyTorch
- Principales caractéristiques
- Installation rapide : optimisation de l’installation et du build des paquets
- Utilisation d’artefacts optimisés et de l’API de métadonnées native de uv lors de l’installation depuis PyPI, PyTorch ou des sources privées internes
- Jusqu’à 10 fois plus rapide que les autres registres privés
- Sécurité et conformité renforcées : réduction des risques grâce à une meilleure compréhension des dépendances et de la supply chain
- Possibilité de générer des URL d’index dédiées pour filtrer les paquets
- Contrôle d’accès aux paquets selon des critères comme la popularité, l’ancienneté de publication ou l’état des vulnérabilités
- Garantie de builds reproductibles côté serveur
- Prise en charge des standards les plus récents
- Compatibilité avec les standards et workflows de packaging Python les plus récents
- Intégration directe avec uv pour une authentification et une utilisation fluides sans configuration supplémentaire
- Distribution de paquets avec détection GPU : simplification du build et de la distribution liés à CUDA et PyTorch
- Fourniture de prébuilds personnalisés pour des bibliothèques GPU comme PyTorch, vLLM, FlashAttention et DeepSpeed
- Maintien d’une configuration optimale selon le matériel et de métadonnées cohérentes
- Installation rapide : optimisation de l’installation et du build des paquets
Problèmes visés
- Difficulté d’installation de bibliothèques liées au GPU comme PyTorch, CUDA, FlashAttention et DeepSpeed
- Gaspillage de ressources dû aux builds répétés du même paquet au sein d’une équipe
- Erreurs de build provoquées par les mises à jour de setuptools
- Complexité du processus d’authentification pour les registres internes
Stratégie d’intégration serveur-client
- Résolution directe de ces problèmes grâce à l’intégration verticale de uv (client) et pyx (serveur)
- Il est possible d’utiliser uniquement uv sans pyx, ou uniquement pyx sans uv, mais la meilleure expérience vient de leur utilisation conjointe
- Une intégration profonde avec les outils open source permet de proposer une expérience de développement auparavant impossible
Modèle économique
- Les outils Astral comme uv, Ruff et ty resteront gratuitement disponibles, open source et sous licence permissive pour toujours
- En parallèle, Astral proposera des services d’hébergement payants comme pyx pour répondre aux besoins d’infrastructure de “l’étape suivante”
État actuel et feuille de route
- Le service est actuellement exploité avec des partenaires de lancement comme Ramp, Intercom et fal
- Jusqu’à la GA (disponibilité générale), Astral veut maintenir une boucle de feedback rapide via un open build
- L’entreprise invite les équipes et les passionnés intéressés à la contacter
4 commentaires
Je me suis surpris à lire l’article en me demandant comment cette entreprise pouvait bien gagner de l’argent, et il semble donc qu’elle prévoit de proposer pyx en version payante.
Dire que All python packaging challenges are solved, c’est quand même assez drôle.
Ce n’est pas vraiment résolu, non ? On a juste rangé ça de façon à ce que ça fonctionne tant bien que mal, non ? haha
Python est un langage majeur utilisé dans le monde entier, mais il est vrai que son environnement est extrêmement désordonné.
Dans les commentaires sur Hacker News, certains s’inquiètent de voir les « entreprises » intervenir, mais ils semblent oublier que si personne n’a rien fait jusqu’à ce que les entreprises s’en mêlent, c’est précisément pour cela qu’on en est arrivé à cette situation.
Pour information : citation de ce que quelqu’un a dit dans les commentaires de Hacker News
Commentaires sur Hacker News
Je partage probablement un billet de blog plus utile : https://astral.sh/blog/introducing-pyx
Je pense que tous les problèmes de packaging Python sont déjà résolus. La leçon à en tirer ici, c’est qu’il n’existe pas de solution unique parfaitement adaptée à tous les problèmes. Renforcer les liens avec des entreprises financées par du capital-risque ou dépendre de leur infrastructure représente toujours un gros risque pour la communauté FOSS
On m’a dit au départ d’utiliser pip, donc j’ai commencé comme ça. Mais c’était lent et j’avais souvent des problèmes. Je suis donc passé à virtualenv, mais ça ne réglait qu’une partie du problème. Ensuite j’ai utilisé conda : parfois ça marchait bien, mais ça mettait mon profil shell en vrac, et il arrivait souvent que les versions de paquets s’emmêlent. Après ça, on m’a recommandé pipenv, qui était bien au début, mais le développement a été abandonné et, après changement d’équipe, ça cassait souvent sur les versions récentes. On m’a ensuite conseillé poetry, mais c’était bien trop lent pour être utilisable. Je suis donc revenu à pip avec venv intégré, mais j’ai retrouvé les mêmes problèmes qu’avant, avec encore moins de fonctionnalités. Je suis alors passé à uv, et là, ça fonctionnait à peu près correctement. Sauf que les dépendances dont j’ai besoin se buildent et se package différemment selon l’OS et le GPU, si bien que mes collègues n’arrivent même pas à installer ce projet sur leur laptop. Quel soulagement d’apprendre que les problèmes de packaging Python sont tous « résolus »
Affirmer que « tous les problèmes de packaging Python sont déjà résolus », c’est franchement parler sans savoir, ou faire preuve d’ignorance. Python n’a toujours aucun moyen fiable de gérer des dépendances natives sur des plateformes variées. pip et setuptools ne devraient pas être l’ultime horizon de cet écosystème
Je partage cette inquiétude, mais depuis que j’utilise uv j’ai économisé énormément de temps, donc je vais continuer jusqu’à ce que les dérives du capital-risque finissent par tout gâcher. D’ici là, j’espère que la communauté pourra se rassembler autour d’une direction commune
Je viens de passer les 3 dernières heures à faire s’affronter Python et Debian, et ma colère contre l’écosystème Python monte en flèche. Rien n’est résolu. Sur Debian, on recommande seulement d’utiliser venv, mais les paquets installés dans un venv sont faciles à rater pour des outils du genre cmake. Il y a aussi des paquets apt-get, que certains outils trouvent exclusivement, tandis que d’autres ne les voient pas. Les noms de paquets ne sont pas cohérents non plus. Ma console m’a recommandé pipx, mais l’expérience est du même ordre. Il reste aussi de vieux résidus de Python 2 vs 3, si bien que la présence ou non du numéro de version fait souvent échouer la détection de paquets. Même si je ne sais pas ce qu’est c++headerparser, tout cela m’a convaincu qu’il vaut mieux extirper Python de l’arbre de build et l’enterrer dans l’histoire
Vous venez d’arriver ou quoi ? Je vous recommande de goûter ce Kool-Aid. Inutile de vous soucier du logo « MongoDB » gravé sur le verre : c’est un vieux modèle
J’ai trop souvent fait confiance à des produits open source pour ensuite me faire brûler. J’ai entendu ces promesses d’innombrables fois. Un jour, il y a un rachat, puis des années de documentation, d’issues et de PR sont nettoyées presque sans avertissement. Ensuite, la nouvelle entreprise sort un produit commercial, mais il lui manque parfois des fonctionnalités essentielles que j’utilisais
Même si je comprends cette inquiétude, je voudrais souligner que pyx est un produit délibérément séparé, contrairement aux outils existants d’Astral. L’annonce officielle dit aussi : « pyx est une concrétisation de la stratégie d’Astral, et les outils d’Astral resteront à jamais gratuits, open source et sous des licences très permissives ». Notre objectif, au lieu de monétiser les outils open source, est de réduire ces craintes en créant un produit distinct, commercialement viable
C’est une inquiétude tout à fait compréhensible. Cela dit, je trouve la réputation et le bilan d’Astral vraiment impressionnants. J’ai été surpris de voir une réaction aussi prudente sur HN. Cela fait plus de 10 ans que je développe en Python, et quand Astral fait quelque chose, j’ai toujours tendance à l’attendre avec intérêt
Si la fonctionnalité avait une vraie valeur, elle aurait été intégrée à pip
Je comprends tout à fait les remarques sur la difficulté d’installer PyTorch, CUDA, FlashAttention ou DeepSpeed. Sous Windows (et WSL), il arrive aussi que certains paquets exigent des compilateurs d’anciennes versions de Visual Studio, ce qui oblige à aller chercher manuellement des chemins de téléchargement pénibles. J’attends une meilleure expérience de développement
En réalité, WSL est presque équivalent à Linux, donc je ne pense pas que la version du compilateur Visual Studio soit très importante. Les binaires WSL sont tous construits avec une toolchain Linux. Même sous Windows, libc est très stable depuis Win10. Les binaires compilés avec VC++ 2015 ou plus récent conservent la compatibilité C-ABI entre eux. Les seuls cas où un ancien compilateur est nécessaire, c’est lorsqu’un langage ou une fonctionnalité particulière n’est pas pris en charge par les compilateurs plus récents, ou lorsqu’on essaie de faire passer directement des objets C++ à travers des ABI. Ces cas sont rares
C’est exactement ce genre d’épisodes qui m’a fait abandonner complètement Ruby à cause de Rails. Quand je regardais des vidéos sur Ruby, tout le monde avait l’air de développer dans la joie, ce qui me rendait un peu jaloux, mais dans mon environnement, pour mettre en place un environnement de développement, il fallait forcément passer par un droplet DigitalOcean, et la compilation pour Rails plantait régulièrement avec des erreurs. Vers 2012, je voulais prendre le train de la hype Rails, mais la configuration et l’installation étaient toujours un cauchemar. Je suis donc passé à Python, et au début ça allait bien, mais aujourd’hui, dès que ça touche à l’IA ou à CUDA, on en revient presque à préférer recopier les scripts shell de quelqu’un d’autre tant l’enfer de l’installation est grand
Je pense que, pour des workflows centrés sur le GPU, le packaging Python devrait aller dans cette direction. Il y a surtout deux choses que j’attends. D’abord, des index validés pour chaque accélérateur (par exemple CUDA/ROCm/CPU) afin que les débats sans fin sur la matrice torch/cu* disparaissent. Ensuite, rendre les métadonnées interrogeables par le client pour permettre des installations en parallèle. Si pyx peut réduire la « boucle d’essais-erreurs avec pip » dans les environnements ML, tout en offrant des builds ciblés par matériel et des hash prévisibles, cela ferait gagner énormément de temps dans la mise en place des environnements. Et garder l’outil lui-même en open source tout en se rémunérant via un service hébergé est positif pour la confiance. Je me demande aussi si pyx prendra en charge des vérifications de supply chain comme le graphe de dépendances, les dépendances inverses (qu’est-ce qui casse si X→Y ?), ou encore SBOM et des preuves de signature
À une époque, il allait de soi qu’un système d’exploitation intègre un compilateur
C’est précisément pour ce genre d’environnements que j’avais choisi anaconda à l’époque
Quelqu’un a lancé la blague : « bientôt, il y aura 14 standards concurrents pour le packaging Python ». En réalité, 14, c’est pour rire : cela fait longtemps qu’il y en a déjà plus que ça
Le packaging Python est, à mon avis, l’aspect de Python qui trahit le plus le Zen de Python
En septembre dernier, Charlie a révélé sur Mastodon qu’il réfléchissait à ce modèle économique : https://hachyderm.io/@charliermarsh/113103564055291456
Je me demande ce que signifie concrètement un registre GPU-aware. Est-ce que cela veut dire que uv pourrait vérifier les caractéristiques de mon GPU et aller automatiquement chercher sur Pyx l’ensemble de paquets adapté ? Si c’est un registre privé et payant pour les clients entreprise, une société pourrait-elle fournir un tel registre publiquement sous forme d’instance externe ? Autrement dit, si j’étais un vendor, pourrais-je exploiter un registre Pyx payant pour mes paquets et l’utiliser comme point d’entrée pour mes clients ?
Je l’ai déjà dit il y a quelques semaines : un jour, Astral mettra en place une stratégie de monétisation. Le point clé ne sera pas Uv, mais plutôt une sorte de PyPI privé protégé : https://news.ycombinator.com/item?id=44712558
Je ne comprends pas très bien le point de ce commentaire. En fait, Charlie Marsh l’a expliqué lui-même en septembre dernier : un registre de paquets privé pour l’entreprise pourrait être un exemple stratégique (pas nécessairement la forme définitive, mais une façon concrète d’illustrer la stratégie envisagée). Astral est très transparent sur son modèle économique : https://hachyderm.io/@charliermarsh/113103605702842937
Le mot « monétisation » peut sonner négativement, mais comme ils ont construit des outils vraiment excellents, les entreprises qui espèrent qu’ils résolvent encore davantage de problèmes seront tout à fait prêtes à payer
Je n’ai pas encore adopté uv, et j’observe la direction qu’ils vont prendre. Récemment, j’ai aussi dû réévaluer l’usage des outils Anaconda à cause des changements de licence, et la même chose s’est produite avec Qt. L’idée de me retrouver face à un nouveau problème de licence me pèse déjà