Maison >développement back-end >Tutoriel Python >L'empaquetage Python est génial maintenant : `uv` est tout ce dont vous avez besoin
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.
Je soutiens que les deux principales difficultés du packaging Python sont
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 élèves et je pense "ce n'est pas bien".
Bien sûr, il existe d'autres problèmes, comme comment créer et publier des packages distribuables. Mais je prétends que cela n’affecte pas la plupart des débutants de Python. De plus, ils sont également en train d’être résolus. Continuez à lire.
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 qu'il remplit 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 :
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 ».
Au 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 aussi 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éveloppeur.
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 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é.
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 première fois, je vois clairement un outil de flux de travail conforme aux normes, complet, exempt de problèmes d'amorçage, 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 que UV est allé bien au-delà de cela et a résolu d'autres problèmes d'expérience de développeur, ce dont 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.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!