Rye : une expérience Python sans friction

 (rye.astral.sh)
2 points par GN⁺ 2024-07-10 | 2 commentaires | Partager sur WhatsApp
  • Rye est un outil de gestion de projets et de paquets conçu pour centraliser l’installation de Python, les projets pyproject.toml, les dépendances, les virtualenv et l’installation d’outils globaux
  • Son développement est désormais arrêté, et il est recommandé d’utiliser uv, le projet successeur créé par les mêmes mainteneurs
  • Les utilisateurs existants peuvent migrer en consultant le guide de migration vers uv ; Rye reste téléchargeable, mais aucune mise à jour supplémentaire n’est prévue
  • L’arrêt des mises à jour inclut aussi les mises à jour de sécurité ; pour les nouveaux projets ou les environnements maintenus sur le long terme, il faut envisager une transition vers uv
  • L’expérience Python unifiée visée par Rye couvrait aussi bien les projets complexes que les monorepos, mais l’effort de maintenance s’est déplacé vers uv

État actuel de Rye

  • Arrêt du développement et recommandation d’uv

    • L’usage de uv est recommandé à tous les utilisateurs
    • uv est le projet successeur créé par les mêmes mainteneurs
    • uv est activement maintenu et bien plus largement utilisé que Rye
    • Les utilisateurs actuels de Rye peuvent consulter le guide de migration vers uv
    • Rye peut continuer à être utilisé, mais aucune mise à jour supplémentaire n’est prévue
    • Aucune mise à jour de sécurité n’est non plus prévue

Fonctionnalités proposées par Rye

  • Rye est une solution de gestion de projets et de paquets pour Python
  • Il a été conçu comme un outil tout-en-un pour les utilisateurs de Python
  • Dans une expérience unifiée, il prend en charge les tâches suivantes
    • gestion de l’installation de Python
    • gestion de projets basés sur pyproject.toml
    • gestion des dépendances
    • gestion des virtualenv
    • installation d’outils globaux
  • Il a été conçu pour gérer des projets complexes et des monorepos
  • Une vidéo de présentation est disponible ici : Watch an introduction

À lire aussi

2 commentaires

 
lum7671 2024-07-11

Cela fait un moment, mais après avoir utilisé diverses choses,
j’utilise Introduction - PDM.

Il va falloir que j’essaie aussi Rye.
 
GN⁺ 2024-07-10
Avis Hacker News

  • Une grande partie du développement du packaging de base se fait désormais dans uv, et Rye utilise uv en interne ; donc quand uv s’améliore, Rye s’améliore aussi.
    Par exemple, uv a récemment ajouté la résolution universelle des dépendances, ce qui permet de produire un requirements.txt verrouillé à partir d’un résultat de résolution unique fonctionnant sur toutes les plateformes et tous les systèmes d’exploitation, pas seulement sur le système en cours d’exécution ; la dernière version de Rye la prend aussi en charge.
    https://github.com/astral-sh/uv
    Comme je développe Rye et uv, je peux répondre si vous avez des questions.

    • Je me demande si la résolution universelle des dépendances de Rye/UV fonctionne correctement aussi avec PyTorch, ou si elle rencontre les mêmes problèmes que Poetry.
      https://github.com/python-poetry/poetry/issues/6409
      https://news.ycombinator.com/item?id=39257501
    • Je me demande s’il existe des travaux ou des plans que l’on peut suivre concernant les fichiers de verrouillage multiplateformes.
      C’est l’une des raisons pour lesquelles l’équipe dont je fais partie hésite à migrer. Comme nous faisons du ML, prenons un projet basé sur PyTorch comme exemple : l’état souhaité serait de placer toutes les dépendances dans pyproject.toml et de pouvoir générer, depuis un Mac AArch64 ou une station de travail Windows AMD64, des fichiers de verrouillage pour les configurations de plateformes suivantes : Mac avec le PyTorch MPS par défaut, Windows avec PyTorch CUDA, Linux AArch64 avec PyTorch CPU, Linux AMD64 avec PyTorch CPU, Linux AMD64 avec PyTorch CUDA.
      Merci d’avoir créé Ruff ; nous sommes très satisfaits à la fois du linting et du formatting.
    • Excellent travail. Avant, je devais de temps en temps configurer l’environnement de travail d’un projet sur un nouvel ordinateur, et pyenv+venv+pip était toujours pénible ; maintenant, je suis passé à Rye.
      Désormais, il suffit d’installer Rye, de récupérer depuis GitHub, puis de taper rye sync, et c’est terminé.
    • Si vous vous occupez à la fois d’uv et de rye, je me demande pourquoi maintenir les deux en parallèle. Pour éviter la confusion liée à la fragmentation et à la charge du choix, ne vaudrait-il pas mieux arrêter rye maintenant ?
    • Beaucoup d’entreprises pour lesquelles la prévisibilité et les bonnes performances des builds comptent migrent, et dans ce processus il devient souvent nécessaire de générer des SBOM pour les injecter dans des outils comme guac.
      https://guac.sh/
      https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
      Grâce à la fonctionnalité récemment ajoutée de déverrouillage des contraintes de dépendances, on peut encourager le maintien de la compatibilité pendant le développement, puis générer un requirements.txt précis et explicite pour la reproductibilité, ce qui rend la gestion des vulnérabilités et l’étape SBOM bien plus simples qu’avec des outils comme Poetry.
      Pour des raisons similaires, j’utilise https://hatch.pypa.io/latest/why/, et j’apprécie aussi le fait que cela fonctionne bien avec uv.

  • Ce qui me rebutait dans Rye, c’est qu’il recommande fortement l’utilisation de builds Python non standards.
    La page de philosophie (https://rye.astral.sh/philosophy/) explique que les builds CPython de python.org sont totalement inadaptés, qu’il n’existe selon les plateformes que des installateurs .msi ou seulement des tarballs, et que les différentes distributions de Python divergent fortement, créant toutes sortes de problèmes dans le sous-écosystème. Le projet utilise donc les builds autonomes d’indygreg, en espérant qu’un jour des builds Python bien maintenus et fiables apparaissent pour remplacer le chaos actuel.
    Les informations sur ces builds indygreg se trouvent ici : https://gregoryszorc.com/docs/python-build-standalone/main/, et il est aussi possible de choisir un autre Python : https://rye.astral.sh/guide/toolchains/
    Cela dit, je n’ai presque jamais rencontré les problèmes dont ils parlent. Les builds Python officiels téléchargés depuis python.org ont fonctionné, les Python ordinaires installés via le gestionnaire de paquets de la distribution ont fonctionné, et le Python inclus dans les images de conteneurs Docker officielles a fonctionné.
    Ces builds spéciaux fonctionnent sans doute bien, mais leur caractère non standard me fait hésiter. Il existe même une liste de particularités de comportement ; je ne comprends pas pourquoi ajouter des particularités à quelque chose qui n’a pas de problème. Le fait que la philosophie de Rye pousse autant à utiliser ces builds le rend aussi moins attirant que des alternatives qui utilisent par défaut le Python déjà présent dans le système d’exploitation.

    • C’est probablement ce genre de situation qui est visé : vous travaillez dans une entreprise qui utilise quelque chose comme un vieux CentOS, le gestionnaire de paquets système ne fournit rien de plus récent que Python 3.6, et les binaires officiels de python.org affichent à l’exécution une erreur indéchiffrable à propos de la version de glibc.
      Compiler Python depuis les sources nécessite de nouvelles dépendances système et prend longtemps, puis finit par produire des erreurs encore plus obscures sur des fichiers d’en-tête manquants. En cherchant ces erreurs, on trouve un flag ./configure qui contourne un problème corrigé par GCC upstream en 2017, et au final ça finit quand même par réussir.
      Si vous n’avez jamais rencontré ce genre d’erreur ni les environnements de build manylinux, vous avez évité tout un monde de douleur. Il en va de même pour le scripting d’installation sous Windows ou pour des points comme les « limitations des instructions CPU disponibles » sur cette page.
    • Il y a deux extrêmes dans les builds, le packaging et la distribution de Python. L’un est la voie royale, l’autre est un couloir aux mille lames. Si la proposition d’un Python portable ne vous parle pas, c’est que vous avez eu de la chance et que vous êtes toujours resté sur la voie royale.

  • Le code source de Python est régulièrement téléchargé, compilé avec les optimisations standard de production, puis installé dans /use/local/python${version} ; depuis la sortie de Python 3.7 en 2018, cela fonctionne de manière très cohérente
    D’après mon expérience, ces commandes sont tellement stables et cohérentes qu’elles pourraient être automatisées. Je me demande quel est exactement le point problématique soulevé par l’auteur, ou quelle est l’objection de fond

    • Dire que « les builds CPython de python.org sont totalement inadéquats » signifie peut-être qu’il n’existe pas de binaires macOS/Windows pour les releases de sécurité des anciennes versions de Python
      Par exemple, on ne peut pas télécharger d’installeur Python 3.10.14, et le dernier installeur Windows est Python 3.10.11, daté du 5 avril 2023
    • D’accord. Il faudrait soutenir la PSF ; défendre une nouvelle « bonne méthode » est une position étrange

  • J’aime bien Rye. Il fait exactement ce qu’il annonce, rend vraiment agréable tout le processus autour de venv, des versions de Python et du packaging, et paraît presque transparent pour quelqu’un qui connaît déjà les usages Python officiels comme pyproject.toml
    En plus, il donne à Python une sensation proche de Cargo, et Cargo est aussi un outil agréable à utiliser

    • Si, comme moi, vous avez ignoré les outils du genre Poetry et êtes resté sur pip-tools, uv, utilisé en interne par Rye, est un substitut direct
      Personnellement, je pense que pip-tools avait une conception bien meilleure que Poetry ou Pipenv. Il était orthogonal à la fois à pip et à virtualenv, deux pratiques déjà intégrées depuis longtemps dans les usages Python. Rye montre qu’une approche conforme aux standards, améliorée par itérations, peut l’emporter
      Au-delà du gain de vitesse dû à Rust, j’aime le fait qu’il fournisse de bons réglages par défaut sur l’emplacement des environnements virtuels (.venv) et sur l’installation de plusieurs versions de Python. Cela peut sembler mineur, mais depuis que les wheels ont réglé les problèmes d’installation de numpy, ces valeurs par défaut raisonnables et des pip-tools intégrés étaient pratiquement tout ce qui manquait. En ce sens, je me demande aussi quelle était encore la raison d’être d’Anaconda après l’arrivée des wheels binaires
    • J’avais commencé avec Python en entendant dire qu’il y avait une seule façon de faire chaque chose, mais l’expérience d’installation et de gestion des environnements était un vrai bazar
      Je suis content de voir que cela s’améliore enfin
    • Si ça « donne à Python une sensation proche de Cargo », je suis déjà convaincu. Poetry a passé toute une journée sans réussir à résoudre les dépendances, donc j’envisageais d’essayer pixi
      On dirait qu’il y a plus de gestionnaires de paquets Python que d’apps de chat Google
    • Je me demande ce que signifie « rend vraiment agréable ». Est-ce trop difficile à résumer ? Avec Anaconda ou Poetry, je n’ai pas vraiment trouvé de points qui donnaient l’impression d’un choix particulier en matière d’expérience utilisateur
      Et côté curation, l’idée de faire davantage confiance à une petite organisation qu’à une organisation plus grande et plus ancienne me paraît difficile à défendre. Autrement dit, je me demande exactement ce qu’il est censé faire. Ce que j’arrive à lire, c’est en gros « un bon gestionnaire de paquets est bon, rapide et bon » ; une page de comparaison ou de philosophie serait appréciable

  • Le cynisme de HN me surprend parfois
    J’aime bien Rye. Depuis que j’ai utilisé des gestionnaires de paquets d’autres langages comme Cargo ou Hex, j’ai toujours regretté que Python n’ait pas de système similaire, et Rye a complètement comblé ce manque. Quand on ne veut pas installer plusieurs outils pour gérer venv, les versions de Python et les dépendances de projet, c’est vraiment appréciable que Rye fasse tout à lui seul

    • Je me demande si tu as essayé conda. Comment Rye se compare-t-il à conda ?
      Je ne vois pas encore très bien ce que donne Rye, mais conda sait aussi très bien gérer venv, les versions de Python et les dépendances de projet
    • D’accord. Rye fonctionne bien pour moi. Je voulais un Cargo pour Python, et jusqu’ici, de mon point de vue, Rye y est parvenu

  • Tomber sur un nouveau gestionnaire de dépendances Python, c’est comme découvrir par hasard un nouveau framework JavaScript

    • Ma philosophie est simple. Si ça doit être un programme distribuable, j’utilise simplement Go ; si je n’ai pas besoin de choses comme des ports, j’utilise Docker ; et si l’équipe IT, ou quelqu’un d’autre, me fournit une machine avec le système d’exploitation et la version de Python utilisés par toute l’organisation, alors venv suffit
      Si vous devez gérer des ports, distribuer un programme, ou si votre bibliothèque dépend de C ou d’éléments du système d’exploitation, mieux vaut se lancer dans du consulting où, une fois payé, vous n’avez pas à maintenir la base de code ni à en assumer la responsabilité
    • Exact. Docker a déjà résolu, il y a environ dix ans, les problèmes de distribution et d’exécution des programmes Python
      Aujourd’hui, on peut même exécuter CUDA et PyTorch dans Docker. Dans ce genre de fil, quand quelqu’un dit « il suffit d’utiliser Docker », la réponse fréquente est « je n’ai pas envie d’apprendre Docker », mais même sans aucune expérience de Docker, lancer un conteneur Python prend 10 minutes
    • Exact. Mais contrairement à des choses comme Poetry, celui-ci est vraiment bon
    • C’est vraiment grave. Du point de vue utilisateur, c’est frustrant qu’après toutes ces années il n’y ait toujours pas de standard

  • pixi(https://pixi.sh/latest/) est bien. Il permet de figer la version de Python et d’installer des paquets depuis conda et PyPI, et il est écrit en Rust

    • Ça a l’air intéressant, mais il est difficile de s’investir sérieusement dans encore un autre écosystème. Le fait de proposer de le récupérer avec curl puis de le passer à bash, avant de demander ensuite de faire eval sur la sortie d’une commande arbitraire, me met mal à l’aise
    • Merci pour le lien. Je me demande si c’est plus rapide que conda
    • pixi est excellent. Pour quelqu’un qui utilise conda, pixi peut servir d’alternative à conda avec des environnements associés à Git/au répertoire du projet, un peu comme devbox/devenv/flox
      Le contexte est un peu complexe. Il y avait conda, écrit en Python par la société Anaconda, et conda-forge, un écosystème open source qui est un canal conda avec des bots de build CI. Ensuite, sous le même parapluie conda-forge, mamba, écrit en C++, est apparu comme alternative à conda ; c’est un véritable remplacement drop-in, au point que alias conda=mamba devrait fonctionner. Aujourd’hui, conda utilise aussi libmamba comme solveur afin de gagner en vitesse
      Ensuite, l’auteur de mamba l’a séparé pour en faire pixi, l’a réécrit en Rust et a changé la philosophie concernant l’emplacement des environnements et leur activation, tout en restant entièrement compatible avec les environnements conda

conda a toujours permis d’installer des paquets PyPI via pip dans les cas où ils ne se trouvaient pas dans les canaux conda, et pixi prend en charge les paquets PyPI via uv. C’est pour cela que pixi est rapide. D’après l’article de blog, il existe aussi d’autres optimisations qui le rendent bien plus rapide que mamba
Si vous utilisez des paquets qui ne sont pas en pur Python, la famille conda est le bon choix. Le choix du gestionnaire de paquets (conda/mamba/pixi) est secondaire
Le problème de PyPI, c’est le manque de rôle de gardien. À cela s’ajoute l’absence d’une méthode standard pour empaqueter les paquets qui ne sont pas en pur Python, ce qui peut faire « fuir » l’environnement ou le rendre non reproductible, surtout quand on ne distribue que les sources et qu’on fait des choses étranges dans setup.py, comme amorcer l’environnement en y incluant même le compilateur
Côté conda, le canal conda-forge assure un contrôle qualité assez solide. Il vérifie les contraintes, les licences, les problèmes de fichiers de licence manquants dans les distributions PyPI, l’isolation des environnements, etc. Bien sûr, ce n’est pas parfait, car les mainteneurs peuvent utiliser un bot officiel qui fusionne automatiquement des changements PyPI avec de mauvaises contraintes de version
Le problème qu’aucun outil ne résout aujourd’hui est centré sur PyPI. Il faut gérer les paquets absents de conda, et les releases de paquets sont, de fait, pratiquement obligées de sortir d’abord sur PyPI
Même lorsqu’on installe via conda un paquet disponible uniquement sur PyPI, certaines de ses dépendances peuvent exister dans conda. À ma connaissance, aucun gestionnaire de paquets n’utilise des paquets conda pour satisfaire les dépendances de paquets PyPI. On peut ajouter manuellement des paquets conda pour satisfaire les dépendances, mais on risque alors de ne pas bénéficier des bonnes contraintes de version
Même quand on écrit un paquet Python open source, il faut généralement, ou il est préférable de, le publier d’abord sur PyPI, même si la configuration ne dépend que des canaux conda. En effet, publier sur le canal conda-forge exige en pratique une existence sur PyPI. C’est pourquoi Rye peut rester utile même pour des gens comme moi, et mérite qu’on s’y intéresse

  • Il est bon de noter que les gens derrière uv (https://astral.sh/blog/uv) ont repris les rênes de ce projet d’Armin
  • La page d’introduction indique : « Rye is still a very experimental tool, but this guide is here to help you get started. »
    Ce projet me fait très envie, mais je compte attendre qu’il atteigne un stade plus mature. J’aime tout ce qu’a sorti l’équipe Astral, donc mes attentes sont élevées
  • Nous utilisons rye pour développer la bibliothèque openai-python, et l’expérience a été excellente
  • Rye a l’air prometteur, et j’ai aussi pris pas mal de plaisir à utiliser Poetry, mais cela m’a vraiment fait respecter la qualité des outils par défaut de Go
    À chaque fois que je démarre un projet Python, j’ai l’impression de devoir réapprendre l’état de l’art de la gestion des dépendances et des environnements virtuels