Le titre de cet article fait référence à Python Packaging is Good Now de Glyph. Je pense qu'il est prudent de dire qu'au cours de ces 8 années, nous sommes passés de « Bon » à « Excellent ». Continuez à lire pour mon raisonnement.

Qu'est-ce qui rend le packaging Python difficile pour les débutants ?

Je soutiens que les deux principales difficultés du packaging Python sont

• Le bootstrapping, c'est-à-dire comment démarrer !
• Activation, c'est-à-dire comment fonctionnent les venvs en Python (voir mon fil de discussion Mastodon, c'est tellement difficile à expliquer !)

Le bootstrapping était un problème souvent négligé. Devrions-nous dire aux gens d'installer Python depuis https://python.org ? La répartition Anaconda ? Comment pouvons-nous empêcher les gens d'utiliser leur gestionnaire de packages système et risquer de tout casser ?

Et n'oubliez pas tout le cycle de vie de l'environnement virtuel. C'est tellement fou à quel point je suis devenu insensible en tant qu'utilisateur de Python de longue date, mais chaque fois que je dois l'expliquer, je vois les visages de mes étudiants et je pense "ce n'est pas bien".

Bien sûr, il existe d'autres problèmes, comme la façon de créer et de publier des packages distribuables. Mais je prétends que cela n’affecte pas la plupart des débutants Python. De plus, ils sont également en train d’être résolus. Continuez à lire.

Entrez UV

Le 15 février, Astral a sorti uv et j'ai immédiatement quitté le navire. Dans le cadre de mon travail, je dois régulièrement installer de nombreuses dépendances potentiellement conflictuelles, et uv a été un soulagement immédiat.

Mais ce qui est intéressant, c'est que maintenant uv est allé bien au-delà de sa phase initiale de « pip plus rapide » et il tient sa promesse d'être « un gestionnaire de projets et de paquets Python complet, rapide, fiable et facile à utiliser ».

Pour en revenir aux problèmes d'amorçage et d'activation que j'ai mentionnés au tout début, comment uv les résout-il ? Considérez ceci :

• uv ne dépend pas de Python lui-même. Les binaires précompilés et autonomes peuvent être facilement installés sur Linux, macOS et Windows.
• uv python gère les versions Python ! Pas besoin de recourir à des mécanismes spécifiques au système d'exploitation, comme pyenv, deadsnakes, ou à des outils lourds comme conda.
• L'outil uv gère les outils dans des environnements centralisés ! Plus besoin de pipx ou de fondus.
• uv init crée un pyproject.toml barebones en utilisant Hatchling comme backend de construction et une mise en page src fonctionnelle avec un README vide et un module factice.
  • Si vous avez besoin de quelque chose de plus sophistiqué, vous pouvez toujours utiliser un copieur ou un emporte-pièce avec un modèle plus sophistiqué.
• uv add ajoute des dépendances à pyproject.toml, crée un venv s'il n'en existait pas et les installe !
• uv lock crée un fichier de verrouillage avec toutes vos dépendances, que vous pouvez ensuite utiliser en synchronisation uv.
  • Et si vous voulez un bon vieux fichier Requirements.txt, uv pip compile le fait pour vous, tout comme pip-tools !
• uv run exécute des scripts et des commandes, encore une fois sans activer explicitement les environnements !

Essentiellement, ceci :

$ mkdir uv-playground
$ cd uv-playground
$ uv init
warning: `uv init` is experimental and may change without warning
Initialized project `uv-playground`
$ uv add click
warning: `uv add` is experimental and may change without warning
Using Python 3.12.3 interpreter at: /usr/bin/python3
Creating virtualenv at: .venv
Resolved 3 packages in 66ms
   Built uv-playground @ file:///tmp/uv-playground
Prepared 2 packages in 430ms
Installed 2 packages in 0.62ms
   click==8.1.7
   uv-playground==0.1.0 (from file:///tmp/uv-playground)
$ tree
.
├── pyproject.toml
├── README.md
├── src
│   └── uv_playground
│       ├── __init__.py
└── uv.lock

3 directories, 4 files
$ uv run python -c "from uv_playground import hello; print(hello())"
warning: `uv run` is experimental and may change without warning
Hello from uv-playground!

Par conséquent, à la question « comment commencer à apprendre Python sur mon ordinateur », vous pouvez désormais répondre universellement : « installer uv ».

Quelques réflexions

Sur le sujet des environnements virtuels, je suis essentiellement d'accord avec Armin quand il dit

npm s'en est sorti sans aucun équivalent "d'activation" et je pense qu'un futur écosystème Python ne trouvera plus non plus beaucoup d'utilité dans l'activation de virtualenv.

Je remarque également que uv init a choisi Hatchling. J'ai toujours eu une légère préférence pour le PDM, mais je pense que cela pourrait être un point de non-retour.

Il a fallu beaucoup de travail à Leah et aux contributeurs pour arriver à ce diagramme de décision pour le guide d'empaquetage PyOpenSci. Mais le fait qu'il existe désormais une base de référence que les gens peuvent modifier au cas où ils auraient des besoins plus spécifiques (par exemple, un backend de construction compatible Meson ou scikit-build) offre encore une fois une bien meilleure expérience de développement.

Sur conda

Le sujet conda vs pip est une autre source courante de confusion. J'étais un utilisateur et un fan de Conda depuis le premier jour, et cela a effectivement sauvé Python d'une mort très claire à une époque où il était très difficile d'installer simplement des éléments sur Windows.

Dans les années qui ont suivi, j'ai souvent fait référence à l'ancien article de blog de Jake VanderPlas expliquant les différences, mais cela semble désormais une cause perdue.

Les problèmes d'interopérabilité entre pip et conda n'ont jamais été entièrement résolus, et même si je pense que les gens de Pixi font un travail fantastique, je pense qu'à long terme, uv gagnera.

Je reconnais pleinement que les packages conda sont mieux structurés autour de la notion de code non Python, et que le monde actuel des « grosses roues sur PyPI » est clairement une solution sous-optimale. Mais l'ensemble de l'écosystème a évolué dans cette direction : la plupart des packages publient désormais des roues précompilées pour une grande variété de plates-formes.

En d'autres termes : conda pourrait ne pas être aussi utile en 2024 qu'il ne l'était en 2014, et il serait peut-être temps d'arrêter de l'enseigner aux débutants et de le considérer comme un outil avancé.

Conclusion

La raison pour laquelle il est un peu trop tôt est que certaines de ces commandes uv sont encore expérimentales et pourraient évoluer dans le futur. Mais pour la toute première fois, je vois clairement un outil de flux de travail conforme aux normes, complet, exempt de problèmes de démarrage, soigneusement conçu et qui peut gagner.

Qu'est-ce que de nombreux critiques d'emballages Python voulaient depuis le début, n'est-ce pas ? Ne pas avoir à choisir parmi de nombreux outils différents. Mais je pense qu'UV est allé bien au-delà de cela et a résolu d'autres problèmes d'expérience de développeur, pour lesquels je suis heureux et reconnaissant.

J'utilise efficacement les UV pour tout et je ne regarde pas en arrière. Je continuerai à recommander cet outil à tout le monde, continuerai à en parler et j'espère qu'il se généralisera.