Der Titel dieses Beitrags bezieht sich auf Glyphs Python-Verpackung ist jetzt gut. Ich denke, man kann mit Sicherheit sagen, dass wir uns in diesen acht Jahren von „Gut“ zu „Großartig“ entwickelt haben. Lesen Sie weiter für meine Argumentation.

Was macht Python-Paketierung für Anfänger schwierig?

Ich behaupte, dass die beiden Hauptschwierigkeiten bei der Python-Paketierung folgende sind:

Bootstrapping, also wie man überhaupt anfängt!
Aktivierung, d. h. wie Venvs in Python funktionieren (siehe meinen Mastodon-Thread, es ist einfach so schwer zu erklären!)

Bootstrapping war ein oft vernachlässigtes Problem. Sollten wir den Leuten sagen, dass sie Python von https://python.org installieren sollen? Die Anaconda-Distribution? Wie verhindern wir, dass Leute ihren Systempaketmanager verwenden und riskieren, alles kaputt zu machen?

Und vergessen Sie nicht den gesamten Lebenszyklus der virtuellen Umgebung. Es ist so verrückt, wie abgestumpft ich als langjähriger Python-Benutzer geworden bin, aber jedes Mal, wenn ich es erklären muss, sehe ich die Gesichter meiner Schüler und denke: „Das ist nicht in Ordnung.“

Sicher gibt es noch andere Probleme, etwa wie man verteilbare Pakete erstellt und veröffentlicht. Aber ich behaupte, dass dies die meisten Python-

Anfänger nicht betrifft. Außerdem werden sie derzeit ebenfalls angegangen. Lesen Sie weiter.

Geben Sie UV ein

Am 15. Februar veröffentlichte Astral UV und ich sprang sofort von Bord. Im Rahmen meiner Arbeit muss ich regelmäßig viele potenziell widersprüchliche Abhängigkeiten installieren, und uv war eine sofortige Erleichterung.

Aber das Interessante ist, dass uv jetzt weit über seine anfängliche „schnellere Pip“-Phase hinausgegangen ist und sein Versprechen erfüllt, „ein umfassender Python-Projekt- und Paketmanager zu sein, der schnell, zuverlässig und einfach zu verwenden ist“.

Um auf die Bootstrapping- und Aktivierungsprobleme zurückzukommen, die ich ganz am Anfang erwähnt habe: Wie löst UV sie? Bedenken Sie Folgendes:

uv hängt nicht von Python selbst ab. Vorkompilierte, eigenständige Binärdateien können problemlos unter Linux, macOS und Windows installiert werden.
uv python verwaltet Python-Versionen! Sie müssen nicht auf betriebssystemspezifische Mechanismen wie Pyenv, Deadsnakes oder schwere Tools wie Conda zurückgreifen.
UV-Tool verwaltet Werkzeuge in zentralisierten Umgebungen! Pipx oder Fades sind nicht mehr erforderlich.
uv init erstellt ein Barebone-pyproject.toml mit Hatchling als Build-Backend und einem funktionierenden SRC-Layout mit einer leeren README-Datei und einem Dummy-Modul.
• Wenn Sie etwas Anspruchsvolleres benötigen, können Sie jederzeit einen Kopierer oder Ausstecher mit einer anspruchsvolleren Vorlage verwenden.
uv add fügt Abhängigkeiten zu pyproject.toml hinzu,
• erstellt ein Venv, falls noch keins existierte und installiert sie!
UV Lock erstellt eine Sperrdatei mit all Ihren Abhängigkeiten, die Sie dann in UV Sync verwenden können.
• Und wenn Sie eine gute alte „requirements.txt“-Datei benötigen, erledigt uv pip compile das für Sie, genau wie pip-tools!
uv run führt Skripte und Befehle aus, wiederum
• ohne explizit Umgebungen zu aktivieren!

Im Wesentlichen Folgendes:

$ mkdir UV-Spielplatz $ CD UV-Spielplatz $ uv init Warnung: „uv init“ ist experimentell und kann sich ohne Vorwarnung ändern Projekt „uv-playground“ initialisiert $ uv hinzufügen klicken Warnung: „uv add“ ist experimentell und kann sich ohne Vorwarnung ändern Verwenden des Python 3.12.3-Interpreters unter: /usr/bin/python3 Erstellen einer virtuellen Umgebung unter: .venv 3 Pakete in 66 ms gelöst Gebauter UV-Spielplatz @ file:///tmp/uv-playground 2 Pakete in 430 ms vorbereitet Installierte 2 Pakete in 0,62 ms Klicken Sie auf ==8.1.7 uv-playground==0.1.0 (aus file:///tmp/uv-playground) $ Baum . ├── pyproject.toml ├── README.md ├── src │   └── uv_playground │   ├── __init__.py └── UV-Sperre 3 Verzeichnisse, 4 Dateien $ uv run python -c „from uv_playground import hello; print(hello())“ Warnung: „uv run“ ist experimentell und kann sich ohne Vorwarnung ändern Hallo vom UV-Spielplatz!

$ 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!

Auf die Frage „Wie fange ich an, Python auf meinem Computer zu lernen“ können Sie jetzt allgemein antworten: „UV installieren“.

Einige Überlegungen

Beim Thema virtuelle Umgebungen stimme ich im Wesentlichen mit Armin überein, wenn er sagt

npm kam ohne jegliches Äquivalent von „Aktivierung“ davon und ich denke, dass ein zukünftiges Python-Ökosystem auch in der Virtualenv-Aktivierung keinen großen Nutzen mehr finden wird.

Mir ist auch aufgefallen, dass uv init das Jungtier ausgewählt hat. Ich hatte immer eine leichte Vorliebe für PDM, aber ich denke, dass dies ein Punkt sein könnte, an dem es kein Zurück mehr gibt.

Es hat Leah und ihren Mitwirkenden viel Arbeit gekostet, dieses Entscheidungsdiagramm für den PyOpenSci-Paketierungsleitfaden zu erstellen. Aber die Tatsache, dass es jetzt eine

Grundlinie gibt, die die Leute ändern können, falls sie spezifischere Anforderungen haben (z. B. ein Meson- oder Scikit-Build-fähiges Build-Backend), sorgt wiederum für eine viel bessere Entwicklererfahrung.

Auf Conda

Das Thema Conda vs. Pip ist eine weitere häufige Quelle der Verwirrung. Ich war vom ersten Tag an ein Conda-Benutzer und -Fan, und es hat Python effektiv vor einem ganz klaren Tod bewahrt, zu einer Zeit, als es sehr schwierig war, einfach Dinge unter Windows zu installieren.

In den darauffolgenden Jahren habe ich oft auf den alten Blog-Beitrag von Jake VanderPlas verwiesen, in dem er die Unterschiede erläuterte, aber inzwischen scheint es eine verlorene Sache zu sein.

Die Interoperabilitätsprobleme zwischen Pip und Conda wurden nie vollständig angegangen, und obwohl ich denke, dass die Pixi-Leute einen fantastischen Job machen, denke ich, dass uv auf lange Sicht gewinnen wird.

Ich erkenne voll und ganz an, dass Conda-Pakete besser nach dem Konzept von Nicht-Python-Code strukturiert sind und dass die aktuelle Welt der „fetten Räder auf PyPI“ eindeutig eine suboptimale Lösung ist. Aber das gesamte Ökosystem hat sich in diese Richtung entwickelt: Die meisten Pakete veröffentlichen jetzt vorkompilierte Räder für eine Vielzahl von Plattformen.

Mit anderen Worten: Conda ist im Jahr 2024 möglicherweise nicht mehr so ​​nützlich wie im Jahr 2014, und es könnte an der Zeit sein, es nicht mehr Anfängern beizubringen und es als fortgeschrittenes Werkzeug zu betrachten.

Abschluss

Der Grund dafür, dass es etwas zu früh ist, ist, dass einige dieser UV-Befehle noch experimentell sind und möglicherweise in Zukunft weiterentwickelt werden. Aber zum ersten Mal überhaupt sehe ich eindeutig ein Workflow-Tool, das standardkonform, umfassend, frei von Bootstrapping-Problemen, sorgfältig gestaltet ist und das

gewinnen kann.

Was viele Kritiker der Python-Paketierung schon immer wollten, oder? Sie müssen nicht aus vielen verschiedenen Tools wählen. Aber ich denke, dass UV weit darüber hinausgegangen ist und andere Probleme mit der Entwicklererfahrung gelöst hat, wofür ich glücklich und dankbar bin.

Ich verwende UV effektiv für alles und schaue nicht zurück. Ich werde dieses Tool weiterhin jedem empfehlen, weiter darüber reden und hoffe, dass es sich weiter verbreitet.