Journal UV un énième packageur python

Posté par  . Licence CC By‑SA.
Étiquettes :
20
23
déc.
2024

On se moque facilement des projets js qui vont et qui viennent mais python n’est pas en reste avec ses toolchains. Pour moi qui n’utilise pas beaucoup python, je dois perpétuellement me référer à la série d’articles pour vérifier quel outil est la “bonne” façon de faire (ou en tout cas pas trop désuète) et comment l’appeler (parce que python -m pip install requests ne me vient pas du premier coup).

Et l’autre jour on m’a dit qu’il y avait un outil qui a l’air super : uv. Encore un nouveau, super. Il lave plus blanc que blanc, il rend le poil brillant, il fait revenir l’être aimé,… ? Bien sûr et pour cocher toutes les cases il est écrit en rust.

Bon il s’avère que j’étais sur un petit outil en python donc essayons la doc d’installation :

curl -LsSf https://astral.sh/uv/install.sh | sh

(Quand je vais leur raconter ça sur linuxfr, faudra que ce soit un vendredi.)

Et l’usage ?

  • créer un projet ? uv init dossier
  • ajouter une dépendance ? uv add ma-super-bibliothèque
  • lancer mon projet ? uv run mon-script.py

Ok c’est rapide ça utilise un environnement virtuel, ça m’a créé quelques fichiers

  • pyproject.toml
  • uv.lock
  • .env/
  • .python-version

Ouai je vois bien à quoi sert chaque fichier.

Au final pour mon usage simple ça fait le job très bien. Je ne sais pas s’il peut servir à créer des wheel comme il faut etc, mais pour ce que je fais de python il a l’air simple et efficace. Il installe les dépendances plus vite que pip et les commandes sont simples à mémoriser.

  • # Série d'articles

    Posté par  (Mastodon) . Évalué à 10 (+7/-0).

    je dois perpétuellement me référer à la série d’articles

    Tu parles de cette série d'articles ? J'attends la troisième partie avec tellement d'impatience, j'ai un projet en suspend depuis des mois parce que je me dis que cette partie va sans doute m'apprendre ce qu'il faut pour le faire correctement.

    • [^] # Re: Série d'articles

      Posté par  . Évalué à 4 (+2/-0).

      Oui j'ai oublié d'ajouter le lien après la rédaction et j'ai toujours du mal à la retrouver.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Rust ?

    Posté par  (Mastodon) . Évalué à 8 (+7/-2).

    Bien sûr et pour cocher toutes les cases il est écrit en rust.

    Comme ça, plutôt que de devoir installer une toolchain, il faut en installer deux !

    • [^] # Re: Rust ?

      Posté par  . Évalué à 9 (+7/-0).

      Pour le coup non puisque je ne le compile pas moi-même j'ai décidé il y a bien longtemps de faire confiance à mon gestionnaire de paquet. Ça demande d'installer quelque chose plutôt que d'utiliser ce qui est dans une installation de python vanilla (ou en tout cas ce qui est sur ma machine), mais je trouve que le confort de l'usage en vaut la peine.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Par les auteurs de ruff

    Posté par  . Évalué à 9 (+8/-0).

    Uv m'a l'air intéressant, j'ai bien envie de l'utiliser "pour de vrai" dans le futur.

    uv est développé par Astral, la boîte qui est derrière ruff, un linter/formateur pour python. Et comme ruff fonctionne vachement bien (et vite), j'ai un a priori positif sur uv.

  • # Perplexe

    Posté par  (site web personnel) . Évalué à 5 (+5/-0).

    Alors pour ma part je suis assez perplexe sur cette vague d'outils Rust pour remplacer des outils Python de l'écosystème Python.

    Je reconnais qu'ils ont des avantages dont le plus frappent étant celui de la rapidité. Ruff a aussi le mérite de faire bouger les choses par rapport à Flake dont la team a vraiment du mal à accepter le fameux "pyproject.toml".

    Mon avis personnel c'est que je ressens ça comme des outils invasifs. Jusque là l'écosystème Python a toujours été autonome, on a donc toujours eu la possibilité de faire des contributions en Python pour nos outils en Python.

    Mais ces outils en Rust si ils sont définitivement adoptés mettront une partie de l'écosystème Python dépendant de la communauté Rust. Ça me semble assez périlleux à long terme. Non pas que je pense que Rust puisse disparaître comme ça, mais le désintérêt de sa communauté pour participer à l'écosystème Python me semble probable à long terme.

    Je ne pense pas que ce soit une invasion dans le sens de phagocyter la communauté Python pour faire passer à Rust, aussi bon que soit ce langage c'est quand même d'un autre niveau. Si on passe le sucre syntaxique différent et le "typage fort", on a quand même aussi le garbage collector à gérer assidûment.

    Au final, j'ai l'impression de faire un peu le dinosaure parce que j'ai une expérience de +20ans en Python comme langage principal et que je reste attaché à des outils qui datent comme Pip, virtualenv ou Flake parce qu'ils font ce qu'il faut comme il faut.

    Pour autant je me dis aussi que je reste enclin à évoluer sur pas mal d'autres sujets quand ça devient nécessaire donc je surveille quand même un peu ces outils en Rust mais pour l'instant ils me semblent de toute façons trop jeune pour que je les intègrent dans mes environnements de développement.

    • [^] # Re: Perplexe

      Posté par  . Évalué à 6 (+4/-0).

      Mon avis personnel c'est que je ressens ça comme des outils invasifs. Jusque là l'écosystème Python a toujours été autonome, on a donc toujours eu la possibilité de faire des contributions en Python pour nos outils en Python.

      Il me semble que l'une des particularité de l'écosystème python c'est d'avoir toujours eu une grande permissivité en vers le code natif avec des bibliothèques comme numpy pour le plus évident qui mixent du code python et du code C.

      C'est toujours plus satisfaisant d'avoir les outils dans le même langages, mais le plafond de performance de python et de rust sont pas les même.

      Après c'est un outil de plus, il y en aura 5 nouveaux d'ici le printemps.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # poetry

    Posté par  . Évalué à 5 (+4/-0).

    Je vais y regarder de plus près mais tout ce qui est décrit dans le journal existe déjà depuis pas mal de temps avec poetry, qui s'inspire aussi de cargo il me semble.

    • [^] # Re: poetry

      Posté par  (site web personnel) . Évalué à 3 (+1/-0).

      Une différence de uv c'est qu'il peut télécharger python, contrairement à tout les autres outils (y compris contrairement à pyenv qui lui le compile, ce qui nécessite d'avoir les dépendances installées, ce qui n'est pas toujours simple).

      Et ensuite un autre intérêt de uv c'est qu'il est extrêmement rapide. Sur la résolution des versions des paquets (l'étape "lock") poetry peut être très lent, alors qu'uv est vraiment très rapide. Ça passe par le fait d'être en rust mais aussi une attention à la performance dans tout le code.

      Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

  • # pdm

    Posté par  . Évalué à 1 (+0/-0).

    nous on utilise pdm et on est content. Un peu long pour upgrade les packages mais ca va.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.