uv, pip oder poetry: womit ihr eure Python-Pakete verwaltet
Alle drei installieren am Ende dieselben Pakete. Der Unterschied liegt darin, wie verlässlich das Ergebnis in einem Jahr noch reproduzierbar ist und wie viel Werkzeugkette ihr dafür pflegen müsst.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Entscheidung fällt nach einem Benchmark und wird an ganz anderer Stelle bezahlt
Die Zahl, die in jeder Diskussion auftaucht, ist die Installationszeit. uv löst Abhängigkeiten in einem Bruchteil der Zeit auf, die pip dafür braucht, und das ist unstrittig. Nur ist die Auflösung im Alltag selten der Engpass. Wer einmal am Tag die Umgebung aktualisiert, spart damit Sekunden. Der Unterschied wird erst dort zu einer Zahl, die im Monatsbericht auftaucht, wo bei jedem Build in der CI neu aufgelöst wird und wo dieser Build hundertmal am Tag läuft.
Der teurere Fehler liegt in der anderen Richtung. Ein Projekt bleibt bei einer requirements.txt ohne feste Fassungen, weil pip ohnehin da ist und niemand ein weiteres Werkzeug einführen will. Ein halbes Jahr später baut derselbe Stand nicht mehr durch, weil irgendwo im Abhängigkeitsbaum eine neue Version erschienen ist. Die Fehlersuche beginnt beim eigenen Code und endet nach einem Tag bei einer indirekten Abhängigkeit, von der niemand wusste, dass sie überhaupt installiert wird.
Und es gibt den dritten Fall, der in Teams am häufigsten Ärger macht: Jeder benutzt etwas anderes. Einer arbeitet mit Poetry, einer mit pip und einer Liste im Kopf, das Image installiert aus einer exportierten Datei, und die CI-Umgebung macht wieder etwas Drittes. Solange nichts schiefgeht, fällt das nicht auf. Sobald eine Fassung irgendwo klemmt, gibt es keine gemeinsame Wahrheit mehr darüber, was eigentlich installiert sein sollte.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Kriterien, an denen die Wahl tatsächlich hängt
Verglichen wird nicht die Auflösungszeit auf einem fremden Projekt, sondern das, was ihr über Jahre merkt: Wiederholbarkeit, Standardtreue, Umfang, Stabilität der Werkzeugkette und der Aufwand für neue Leute im Team.
pip mit venv
der mitgelieferte Installer, überall vorhanden, macht ausschließlich das Installieren und kennt kein Projektmodell
Poetry
Projektwerkzeug aus der Gemeinschaft mit eigener Auflösung, eigenem Lockfile, Umgebungsverwaltung und Veröffentlichungsfunktion
uv
in Rust geschriebenes Werkzeug von Astral, das Auflösung, Lockfile, Umgebungen, Python-Fassungen und Werkzeuge in einem Programm zusammenfasst
| Entscheidungsfrage | pip mit venv | Poetry | uv |
|---|---|---|---|
| Wie schnell sind Auflösung und Installation im Alltag? | Kommt darauf an Für ein kleines Projekt völlig ausreichend. Bei einem großen Abhängigkeitsbaum mit widersprüchlichen Anforderungen kann die Auflösung dagegen in Minuten laufen, weil pip die Kandidaten der Reihe nach herunterlädt, um überhaupt an ihre Anforderungen zu kommen. | Kommt darauf an Die Auflösung ist gründlich und daher spürbar, vor allem beim ersten Erzeugen des Lockfiles. Wiederholte Installationen aus einem vorhandenen Lockfile sind dagegen zügig, weil dabei nichts mehr aufgelöst werden muss. | Stärke Auflösung und Installation liegen um Größenordnungen darunter, unter anderem weil die Metadaten gezielt geholt und Wheels über einen gemeinsamen Zwischenspeicher hart verlinkt statt kopiert werden. Auf einem frischen CI-Runner ist das der sichtbarste Unterschied. |
| Wie verlässlich lässt sich ein Stand später wiederherstellen? | Kommt darauf an Von Haus aus gar nicht, eine requirements.txt ohne feste Fassungen ergibt an zwei Tagen zwei Ergebnisse. Mit erzeugten Dateien samt Prüfsummen wird es verlässlich, dafür braucht es aber einen zusätzlichen Schritt und die Disziplin, ihn nie zu überspringen. | Stärke Das Lockfile entsteht von selbst, enthält alle indirekten Abhängigkeiten mit Prüfsummen und wird bei jeder Installation berücksichtigt. Genau dafür wurde das Werkzeug gebaut, und das merkt man im Alltag. | Stärke uv.lock wird bei jedem Befehl im Projekt automatisch aktuell gehalten und deckt mehrere Betriebssysteme und Python-Fassungen in einer Datei ab. Der Zustand der Umgebung wird dabei gegen das Lockfile abgeglichen, statt nur ergänzt. |
| Wie gut hält sich das Werkzeug an die veröffentlichten Standards? | Stärke pip ist die Umsetzung dieser Standards und setzt neue Festlegungen in der Regel zuerst um. Das standardisierte Format pylock.toml aus PEP 751 kann pip inzwischen sowohl über den experimentellen Befehl pip lock erzeugen als auch mit -r pylock.toml wieder einlesen. | Kommt darauf an Poetry ist mit einem eigenen Format gestartet und hat den Anschluss nachgeholt: Seit Version 2.0 vom Januar 2025 wird der standardisierte Abschnitt project in der pyproject.toml gelesen. Das eigene Lockfile bleibt aber ein eigenes Format, der Export nach pylock.toml läuft über ein Zusatzmodul. | Stärke uv setzt von Anfang an auf den standardisierten Abschnitt project, kann uv.lock nach pylock.toml ausgeben und bringt mit uv pip eine Schnittstelle mit, die sich absichtlich wie pip verhält. Damit bleibt ein Rückweg offen, und das ist bei einem jungen Werkzeug einiges wert. |
| Wie viel deckt das Werkzeug jenseits der Installation ab? | Schwäche Bewusst wenig. pip installiert, venv legt Umgebungen an, alles andere sind eigene Werkzeuge: eines für den Bau, eines für die Veröffentlichung, eines für Werkzeuge auf der Kommandozeile und eines für die Python-Fassungen. Die Dokumentation von pip sagt selbst, dass es kein Werkzeug zur Projektverwaltung ist. | Kommt darauf an Projektbeschreibung, Auflösung, Umgebung, Bau und Veröffentlichung kommen aus einer Hand, inklusive Abhängigkeitsgruppen für Test und Entwicklung. Nicht abgedeckt sind die Installation von Python-Fassungen und die Verwaltung globaler Werkzeuge. | Stärke Zusätzlich zum Projekt verwaltet uv die Python-Fassungen selbst, installiert Werkzeuge in eigene Umgebungen, führt Skripte mit eingebetteten Abhängigkeiten aus und kennt mehrere Pakete in einem Repository als Arbeitsbereich. Für einen neuen Rechner bedeutet das ein Werkzeug statt vier. |
| Wie ruhig verhält sich die Werkzeugkette über Jahre? | Stärke Beides gehört zur offiziellen Werkzeugkette, wird von der Python Packaging Authority gepflegt und ändert sein Verhalten selten und angekündigt. Für Systeme mit langer Laufzeit und wenig Pflege ist das ein handfestes Argument. | Stärke Poetry ist seit Jahren im Einsatz und hat mit dem Sprung auf Version 2 eine größere Umstellung hinter sich, unter anderem sind Export und die eingebaute Shell in Zusatzmodule ausgelagert worden. Der aktuelle Stand ist Version 2.4.1, und die Änderungsrate ist überschaubar. | Kommt darauf an uv steht im August 2026 bei 0.12 und folgt ausdrücklich nicht der üblichen Versionslogik: Nicht abwärtskompatible Änderungen kommen in der mittleren Stelle. Das Projekt bezeichnet sich selbst als stabil und produktiv einsetzbar, wer die Fassung im Bau nicht festnagelt, bekommt die Änderungsrate aber zu spüren. |
| Wie schnell findet sich jemand zurecht, der neu dazukommt? | Stärke Jede Anleitung im Netz, jede ältere Antwort in einem Forum und jedes Lehrbuch beschreiben diesen Weg. Wer Python kann, kennt ihn. Der Preis dafür ist, dass viele dieser Anleitungen die Fassungen offen lassen und damit ein Problem beschreiben statt einer Lösung. | Kommt darauf an Das Projektmodell ist schnell verstanden, die Befehle sind wenige. Verwirrung entsteht regelmäßig an zwei Stellen: wo die Umgebung eigentlich liegt und was beim Sprung auf Version 2 in Zusatzmodule ausgelagert wurde. | Kommt darauf an Die Befehle sind knapp und die Fehlermeldungen ungewöhnlich gut lesbar. Verwirrend ist für viele, dass es zwei Welten nebeneinander gibt: das Projektmodell mit uv sync und uv run und die pip-artige Schnittstelle unter uv pip, die kein Lockfile anfasst. |
Wie schnell sind Auflösung und Installation im Alltag?
Für ein kleines Projekt völlig ausreichend. Bei einem großen Abhängigkeitsbaum mit widersprüchlichen Anforderungen kann die Auflösung dagegen in Minuten laufen, weil pip die Kandidaten der Reihe nach herunterlädt, um überhaupt an ihre Anforderungen zu kommen.
Die Auflösung ist gründlich und daher spürbar, vor allem beim ersten Erzeugen des Lockfiles. Wiederholte Installationen aus einem vorhandenen Lockfile sind dagegen zügig, weil dabei nichts mehr aufgelöst werden muss.
Auflösung und Installation liegen um Größenordnungen darunter, unter anderem weil die Metadaten gezielt geholt und Wheels über einen gemeinsamen Zwischenspeicher hart verlinkt statt kopiert werden. Auf einem frischen CI-Runner ist das der sichtbarste Unterschied.
Wie verlässlich lässt sich ein Stand später wiederherstellen?
Von Haus aus gar nicht, eine requirements.txt ohne feste Fassungen ergibt an zwei Tagen zwei Ergebnisse. Mit erzeugten Dateien samt Prüfsummen wird es verlässlich, dafür braucht es aber einen zusätzlichen Schritt und die Disziplin, ihn nie zu überspringen.
Das Lockfile entsteht von selbst, enthält alle indirekten Abhängigkeiten mit Prüfsummen und wird bei jeder Installation berücksichtigt. Genau dafür wurde das Werkzeug gebaut, und das merkt man im Alltag.
uv.lock wird bei jedem Befehl im Projekt automatisch aktuell gehalten und deckt mehrere Betriebssysteme und Python-Fassungen in einer Datei ab. Der Zustand der Umgebung wird dabei gegen das Lockfile abgeglichen, statt nur ergänzt.
Wie gut hält sich das Werkzeug an die veröffentlichten Standards?
pip ist die Umsetzung dieser Standards und setzt neue Festlegungen in der Regel zuerst um. Das standardisierte Format pylock.toml aus PEP 751 kann pip inzwischen sowohl über den experimentellen Befehl pip lock erzeugen als auch mit -r pylock.toml wieder einlesen.
Poetry ist mit einem eigenen Format gestartet und hat den Anschluss nachgeholt: Seit Version 2.0 vom Januar 2025 wird der standardisierte Abschnitt project in der pyproject.toml gelesen. Das eigene Lockfile bleibt aber ein eigenes Format, der Export nach pylock.toml läuft über ein Zusatzmodul.
uv setzt von Anfang an auf den standardisierten Abschnitt project, kann uv.lock nach pylock.toml ausgeben und bringt mit uv pip eine Schnittstelle mit, die sich absichtlich wie pip verhält. Damit bleibt ein Rückweg offen, und das ist bei einem jungen Werkzeug einiges wert.
Wie viel deckt das Werkzeug jenseits der Installation ab?
Bewusst wenig. pip installiert, venv legt Umgebungen an, alles andere sind eigene Werkzeuge: eines für den Bau, eines für die Veröffentlichung, eines für Werkzeuge auf der Kommandozeile und eines für die Python-Fassungen. Die Dokumentation von pip sagt selbst, dass es kein Werkzeug zur Projektverwaltung ist.
Projektbeschreibung, Auflösung, Umgebung, Bau und Veröffentlichung kommen aus einer Hand, inklusive Abhängigkeitsgruppen für Test und Entwicklung. Nicht abgedeckt sind die Installation von Python-Fassungen und die Verwaltung globaler Werkzeuge.
Zusätzlich zum Projekt verwaltet uv die Python-Fassungen selbst, installiert Werkzeuge in eigene Umgebungen, führt Skripte mit eingebetteten Abhängigkeiten aus und kennt mehrere Pakete in einem Repository als Arbeitsbereich. Für einen neuen Rechner bedeutet das ein Werkzeug statt vier.
Wie ruhig verhält sich die Werkzeugkette über Jahre?
Beides gehört zur offiziellen Werkzeugkette, wird von der Python Packaging Authority gepflegt und ändert sein Verhalten selten und angekündigt. Für Systeme mit langer Laufzeit und wenig Pflege ist das ein handfestes Argument.
Poetry ist seit Jahren im Einsatz und hat mit dem Sprung auf Version 2 eine größere Umstellung hinter sich, unter anderem sind Export und die eingebaute Shell in Zusatzmodule ausgelagert worden. Der aktuelle Stand ist Version 2.4.1, und die Änderungsrate ist überschaubar.
uv steht im August 2026 bei 0.12 und folgt ausdrücklich nicht der üblichen Versionslogik: Nicht abwärtskompatible Änderungen kommen in der mittleren Stelle. Das Projekt bezeichnet sich selbst als stabil und produktiv einsetzbar, wer die Fassung im Bau nicht festnagelt, bekommt die Änderungsrate aber zu spüren.
Wie schnell findet sich jemand zurecht, der neu dazukommt?
Jede Anleitung im Netz, jede ältere Antwort in einem Forum und jedes Lehrbuch beschreiben diesen Weg. Wer Python kann, kennt ihn. Der Preis dafür ist, dass viele dieser Anleitungen die Fassungen offen lassen und damit ein Problem beschreiben statt einer Lösung.
Das Projektmodell ist schnell verstanden, die Befehle sind wenige. Verwirrung entsteht regelmäßig an zwei Stellen: wo die Umgebung eigentlich liegt und was beim Sprung auf Version 2 in Zusatzmodule ausgelagert wurde.
Die Befehle sind knapp und die Fehlermeldungen ungewöhnlich gut lesbar. Verwirrend ist für viele, dass es zwei Welten nebeneinander gibt: das Projektmodell mit uv sync und uv run und die pip-artige Schnittstelle unter uv pip, die kein Lockfile anfasst.
Was passt wann
- Wenn ihr ein neues Projekt beginnt und niemand an einer bestehenden Werkzeugkette hängt
- nehmt uv, tragt die Abhängigkeiten in die pyproject.toml ein und legt uv.lock ins Repository.
- Wenn Poetry läuft, das Lockfile gepflegt ist und die Auflösung niemanden aufhält
- lasst es so und steckt die Zeit in das Lockfile im Bau und in die Aktualisierung der Abhängigkeiten.
- Wenn ihr aus Betriebsgründen bei der mitgelieferten Werkzeugkette bleiben müsst
- bleibt bei pip, erzeugt euch aber ein Lockfile mit Prüfsummen und installiert im Bau nur noch daraus.
Fünf Fragen, und das Werkzeug steht fest
- 01 Ist das Projekt neu? Dann spricht wenig gegen uv und viel gegen eine offene Liste.
- 02 Gibt es schon ein funktionierendes Lockfile? Dann ist der Umbau eine Kostenfrage.
- 03 Wie oft löst die CI-Umgebung am Tag auf? Erst diese Zahl macht Geschwindigkeit zum Argument.
- 04 Hängt ihr an einem eigenen Index mit Anmeldung? Das entscheidet sich vor allem anderen.
- 05 Wer richtet neue Rechner ein? Je seltener das jemand macht, desto mehr zählt ein bekannter Weg.
Was du danach in einer Sitzung festlegst
Die Wahl hängt an fünf Fragen, die alle innerhalb einer Stunde zu beantworten sind, und an einer Einschätzung dazu, wie viel Umbau ihr euch in den nächsten Wochen leisten wollt.
Neues Projekt oder Bestand unterscheiden
Bei einem neuen Projekt gibt es kaum ein Argument gegen uv: Es liest die standardisierte pyproject.toml, legt Umgebung und Lockfile an und holt bei Bedarf die passende Python-Fassung selbst. Im Bestand mit funktionierendem Poetry-Setup ist der Nutzen kleiner als der Umbau an Images, Bauschritten und Anleitungen.
Ein Lockfile ist Pflicht, das Werkzeug dahinter nicht
Der größte Sprung an Verlässlichkeit liegt nicht zwischen den drei Werkzeugen, sondern zwischen offener Abhängigkeitsliste und festgehaltenen Fassungen samt indirekter Abhängigkeiten. Wer bei pip bleiben will, kann sich diese Datei erzeugen lassen, statt Fassungen von Hand einzutragen.
Die CI-Umgebung ehrlich rechnen
Zähl nach, wie oft am Tag Abhängigkeiten aufgelöst und installiert werden und wie lange das jeweils dauert. Erst diese Zahl sagt dir, ob die Geschwindigkeit ein Argument ist oder nur ein angenehmes Detail auf dem eigenen Rechner.
Ein Werkzeug pro Repository, ohne Ausnahme
Zwei Wege nebeneinander bedeuten zwei Anleitungen, zwei Pfade im Bau und regelmäßig die Frage, warum es beim einen läuft und beim anderen nicht. Die Festlegung gehört sichtbar in die Datei, die jeder neue Kollege zuerst liest, und sie gilt auch für die CI-Umgebung.
Die interne Paketquelle vorher prüfen
Wenn ihr einen eigenen Index oder einen Spiegel mit Anmeldung betreibt, ist das der Punkt, an dem ein Wechsel stillsteht. Prüf vor der Entscheidung, wie das neue Werkzeug Zugangsdaten und zusätzliche Quellen konfiguriert, und probier es an einem kleinen Repository aus, bevor ihr das große umstellt.
Die Abhängigkeit vom Anbieter benennen
pip wird von der Python Packaging Authority gepflegt und ist Teil der offiziellen Werkzeugkette. Poetry kommt aus der Community. uv kommt von einem Unternehmen, ist quelloffen und wird sehr schnell weiterentwickelt. Das ist kein Ausschlusskriterium, aber es gehört in die Entscheidung, statt später zur Überraschung zu werden.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die drei Werkzeuge lösen nicht dieselbe Aufgabe
pip ist ein Installer. Es bekommt Namen und Fassungsbereiche, löst daraus einen Baum auf und legt die Ergebnisse in das site-packages der aktuellen Umgebung. Es kennt kein Projekt, keine Abhängigkeitsgruppen und keinen Zustand, den es abgleichen könnte. Deshalb kann eine Umgebung mit pip auch Pakete enthalten, die längst niemand mehr braucht: Sie wurden installiert und nie wieder entfernt, weil pip nicht weiß, dass sie überflüssig sind.
Poetry beschreibt dagegen das Projekt. In der pyproject.toml stehen die Abhängigkeiten mit Gruppen für Entwicklung und Test, daraus entsteht ein Lockfile, und die Installation gleicht die Umgebung mit dieser Datei ab. Dazu kommen der Bau von Paketen und das Veröffentlichen. Wer eine Bibliothek entwickelt, bekommt damit die gesamte Kette in einem Werkzeug.
uv deckt beides ab und noch mehr. Es hat ein Projektmodell mit Lockfile und Arbeitsbereichen, es kann Python-Fassungen herunterladen und verwalten, es installiert Werkzeuge in eigene Umgebungen, und es führt Skripte mit eingebetteten Abhängigkeiten aus. Daneben steht mit uv pip eine Schnittstelle, die sich absichtlich wie pip verhält, damit bestehende Skripte weiterlaufen. Diese Doppelrolle ist praktisch und gleichzeitig die häufigste Quelle von Missverständnissen, weil die pip-artigen Befehle das Lockfile bewusst nicht anfassen.
Lockfiles und der erste gemeinsame Nenner seit Jahren
Ein Lockfile hält fest, welche Fassung jedes Pakets installiert wird, einschließlich der Abhängigkeiten, die niemand ausdrücklich angefordert hat, und in der Regel mit Prüfsumme. Genau das unterscheidet einen wiederholbaren Bau von einem, der zufällig gerade funktioniert. Poetry und uv erzeugen sie von selbst, bei pip ist es ein eigener Schritt, den man auch weglassen kann, und genau deshalb wird er oft weggelassen.
Neu ist, dass es dafür seit PEP 751 ein werkzeugübergreifendes Format gibt. Der Dateiname ist pylock.toml, die Festlegung wurde Ende März 2025 angenommen und wird inzwischen von der Python Packaging Authority gepflegt. uv kann sein eigenes Lockfile in dieses Format ausgeben, Poetry unterstützt den Export über das Zusatzmodul für den Export, und pip kann solche Dateien sowohl erzeugen als auch als Eingabe für die Installation lesen. Beide pip-Seiten sind ausdrücklich als experimentell gekennzeichnet.
Für die Werkzeugwahl bedeutet das eine spürbare Entlastung. Bisher hieß die Entscheidung auch, sich an ein Sperrformat zu binden, das kein anderes Werkzeug lesen kann. Mit einem gemeinsamen Format wird aus dem Wechsel eher eine Frage der Befehle und der Bauschritte als eine Frage des Datenformats. Verlassen solltet ihr euch darauf noch nicht überall, aber es ist der Grund, warum die Entscheidung heute weniger endgültig ist als vor zwei Jahren.
Was ein Wechsel wirklich kostet
Der Umbau im Projekt selbst ist der kleinste Teil. Die Abhängigkeiten stehen bereits in der pyproject.toml, und die Übernahme ist meist an einem Vormittag erledigt. Die Arbeit steckt drumherum: in den Dockerfiles, in den Vorlagen der CI-Umgebung, in den Zwischenspeichern, die auf bestimmte Dateinamen zeigen, in den Aufgaben zum automatischen Aktualisieren der Abhängigkeiten und in jeder Anleitung, die jemand einmal geschrieben hat.
Am längsten dauert erfahrungsgemäß die Anbindung an eine interne Paketquelle. Wenn ihr einen eigenen Index oder einen Spiegel mit Anmeldung betreibt, unterscheiden sich die Werkzeuge darin, wie zusätzliche Quellen konfiguriert werden, wie Zugangsdaten hinterlegt werden und wie mit Paketen umgegangen wird, die es sowohl intern als auch öffentlich gibt. Das ist gleichzeitig ein Sicherheitsthema, weil eine falsch gesetzte Reihenfolge dazu führen kann, dass ein öffentliches Paket ein internes verdrängt.
Deshalb lohnt sich ein Vorgehen in drei Schritten: erst ein kleines, unkritisches Repository umstellen und dort Bau, Image und interne Quelle durchspielen, dann die Anleitung schreiben, dann die großen Projekte nachziehen. Wer umgekehrt anfängt, hält das Team auf, während noch grundsätzliche Fragen offen sind.
Betrieb, Lieferkette und die Frage nach dem Anbieter
Ein Punkt, der bei der Werkzeugwahl selten mitgedacht wird, ist der Schutz vor manipulierten Paketen. Angriffe über die Lieferkette laufen häufig so ab, dass ein Paket kurzzeitig in einer bösartigen Fassung veröffentlicht und schnell wieder zurückgezogen wird. Wer automatisch aktualisiert, holt sich genau in diesem Fenster das falsche Paket. Beide großen Werkzeuge haben darauf reagiert: uv kann Pakete ausschließen, die nach einem bestimmten Zeitpunkt veröffentlicht wurden, und pip kennt inzwischen einen entsprechenden Schalter beim Auflösen.
Der zweite Punkt sind Prüfsummen. Ein Lockfile mit Prüfsummen sorgt dafür, dass genau die Datei installiert wird, die beim Auflösen geprüft wurde, auch wenn im Index dazwischen etwas ausgetauscht wurde. Bei Poetry und uv ist das der Normalfall, bei pip musst du es ausdrücklich einrichten, und dann lehnt pip jede Installation ohne passende Prüfsumme ab.
Bleibt die Frage nach dem Anbieter. pip und venv kommen aus der offiziellen Werkzeugkette, Poetry ist ein Projekt der Gemeinschaft, uv wird von einem Unternehmen entwickelt, das damit auch geschäftliche Absichten verbindet. Der Quelltext ist offen und die Formate sind offengelegt, ein echtes Ausschlusskriterium ist das also nicht. Wer in einem regulierten Umfeld arbeitet, sollte die Abwägung trotzdem einmal aufschreiben, statt sie später erklären zu müssen.
Dazu passende Kurse
Wenn die Werkzeugkette im Team gerade neu festgelegt wird, geben Python-Kurse rund um Pakete und Abhängigkeiten die gemeinsame Grundlage dafür.
Weil der eigentliche Aufwand in Images, Zwischenspeichern und Bauschritten steckt, gehören DevOps-Kurse für Bau und Auslieferung zur selben Entscheidung.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Häufige Fragen
Ersetzt uv jetzt pip vollständig?
Können wir Poetry und uv nebeneinander benutzen?
Brauchen wir überhaupt ein Lockfile, wenn wir Container ausliefern?
Was passiert mit unserer requirements.txt?
Wie oft sollten wir Abhängigkeiten aktualisieren?
Quellen
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Umstellung einmal an einem echten Projekt durchspielen
Im Packaging-Kurs bei cmt richtest du Projektbeschreibung, Lockfile und Bau mit uv und poetry nebeneinander ein und siehst dabei, an welchen Stellen ein Wechsel im eigenen Bestand wirklich Arbeit macht.
Passt dazu
- Wann du in Python eine virtuelle Umgebung brauchst und wann nicht
- pytest läuft lokal, scheitert in der CI: die häufigsten Ursachen
- Python ohne GIL: was der freie Threading-Modus für euren Code ändert
- Type Hints in Python: was sie bringen und wo mypy anschlägt