Reading Time: 11 minutes

Schlüssel zum Mitnehmen

  • UV ist der Standard-Python-Paketmanager für wissenschaftliches Rechnen geworden – 10- bis 100-mal schneller als PIP, mit deterministischen Lockfiles, die Forschungs-Workflows reproduzierbar machen.
  • Ruff Ersetzt Black, Isort, Flake8, Pyupgrade und Autoflake in einer einzigen rostbasierten Binärdatei. Scipy, Pandas und andere wichtige wissenschaftliche Bibliotheken verwenden es heute.
  • Ty (veröffentlicht Dezember 2025) ist 20- bis 100-mal schneller als MYPY und verwendet eine schrittweise Garantie, die nicht den nicht kommentierten Code bricht – ideal für die Migration von Forschungscodebasen.
  • pyproject.toml ist jetzt die einzige Konfigurationsquelle für die gesamte Toolchain und ersetzt verstreute Konfigurationsdateien wie .flake8, .isort.cfg und mypy.ini.
  • speziell für das wissenschaftliche Rechnen, Conda bleibt für Nicht-Python-Abhängigkeiten (MPI, CUDA, HDF5) erforderlich, und Pyright ist nach wie vor die sicherere CI-Wahl, bis TY Version 1.0 erreicht.

Wenn Sie 2026 wissenschaftliche Python-Workflows ausführen, hat sich Ihre Toolchain grundlegend geändert. Die Pakete, die Sie für die Berechnung verwenden – Numpy, Scipy, Fipy und der Rest – sind identisch. Wie Sie sie installieren, verwalten, fusseln und überprüfen, unterscheidet sich jedoch von den meisten Tutorials, älteren Anleitungen und Notebooks für das Universitätslabor.

Astral, das Unternehmen hinter Pythons beliebtester Linter (Ruff), hat drei Tools entwickelt, die jetzt den gesamten Entwickler-Workflow abdecken: UV für die Paketverwaltung, ruff für das Flinten und Formatieren und ty für den Typ Überprüfung. Zusammen ersetzen sie PIP, VENV, BLACK, ISort, Flake8 und myPy. Das sind sechs Werkzeuge, die in drei zusammengefasst sind, alle aus einer einzigen pyproject.toml-Datei konfiguriert.

Dieser Artikel behandelt die moderne wissenschaftliche Python-Toolchain im Jahr 2026. Er erklärt, was jedes Werkzeug tut, warum die Verschiebung stattgefunden hat und wie alles eingerichtet werden kann – einschließlich der Macken und Einschränkungen, die für das wissenschaftliche Rechnen wichtig sind. Wenn Sie ein neues Simulationsprojekt einrichten, eine vorhandene Codebasis migrieren oder nach dem Leitfaden „Scientific Python Ecosystem“ aufholen (siehe Artikel # 364 ), dies ist das praktische Update, das Sie benötigen.

Die moderne Werkzeuglandschaft

Bis etwa 2024 sah der wissenschaftliche Python-Entwickler-Workflow folgendermaßen aus:

  • Paketmanagement: Pip mit Pip-Tools oder Poesie
  • Virtual Environments: Venv oder VirtualEv
  • Python-Versionsverwaltung: Pyenv oder Pyenv-VirtualEnv
  • Fusseln: Flake8, dann PydocStyle plus Pylint für Style-Checks
  • Formatierung: schwarz und isort (und später AutoPEP8 und Pyupgrade)
  • Typprüfung: mypy

Das bedeutete, sechs separate Python-Pakete zu installieren, separate Konfigurationsdateien zu verwalten und durch sequentielle Auflösungsschritte zu warten. Eine einfache pip install kann Minuten dauern. Schwarz laufen, dann isort, dann flocke8, dann könnte mypy noch länger dauern.

Die Verschiebung begann, als Astral Ruff im Jahr 2023 veröffentlichte. Ruff wurde in Rust geschrieben, um Black, Isort, Flake8, Pyupgrade und Autoflake gleichzeitig zu ersetzen, und lief um Größenordnungen schneller als die Python-basierten Alternativen. Dieser Adoptionserfolg gab Astral den Schwung, ein vollständiges Ökosystem aufzubauen: UV für das Paketmanagement und TY für die Typprüfung.

Ende 2025 und Anfang 2026 war die Konvergenz abgeschlossen. Der Scientific Python-Entwicklungshandbuch Jetzt offiziell Empfiehlt Ruff für Style-Checks und TY für die Typprüfung. Scipy und Pandas haben Ruff adoptiert. UV hat die Poesie bei der Akzeptanz unter wissenschaftlichen Computerteams überholt. Der alte Stapel ist nicht tot – er funktioniert immer noch -, ist aber nicht mehr der Standard für neue Projekte.

Warum pyproject.toml wichtig ist

Eine der größten praktischen Änderungen ist das Konfigurationsmodell. Der alte Stack verstreut die Konfiguration über fünf oder mehr Dateien:

  • .flake8 für Fussregeln
  • .isort.cfg zur Importsortierung
  • mypy.ini für das Verhalten der Typprüfung
  • setup.cfg für Paketmetadaten
  • pyproject.toml (teilweise für Build-Systeme)

Modernes Tooling zentralisiert alles in pyproject.toml. Eine einzelne Datei definiert das Paket, die Abhängigkeiten, die Dev-Tools und die Werkzeugkonfiguration. Dies erleichtert das Teilen, Klonen und Pflegen von Projekten – genau das, was Forschungsteams benötigen, wenn sie Code veröffentlichen oder neue Studenten an Bord nehmen.

UV: Paketverwaltung, die tatsächlich funktioniert

uv ist ein rostbasierter Paketmanager, der von Astral erstellt wurde. Es ersetzt PIP, PIP-Tools, PIPX, PYENV und VirtualEnv in einer einzigen schnellen Binärdatei. Im Gegensatz zu PIP erfordert uv nicht die Installation von Python. Es kann einen Python-Interpreter bootstrapen und Versionen neben Abhängigkeiten verwalten.

Warum Forscher wechseln

Die Hauptgründe, warum Forscher und Entwickler uv wählen:

  1. Geschwindigkeit. uv Installiert Pakete 10 bis 100 Mal schneller als PIP, hauptsächlich durch parallele Auflösung und aggressives Caching. Dies ist in CI-Pipelines von Bedeutung, bei denen die Installationszeit direkt die Turnaround-Entwickler beeinflusst.
  2. Sperrdateien. Eine einzelne uv.lock Datei zeichnet exakte aufgelöste Versionen jeder Abhängigkeit auf, einschließlich der Unterabhängigkeit. Durch das Festschreiben dieser Datei an Git wird Ihre Umgebung vollständig reproduzierbar – eine Anforderung für veröffentlichte Simulationen.
  3. Python-Versionsverwaltung. uv kann Python-Interpreter herunterladen und verwalten, sodass keine separaten Tools wie Pyenv erforderlich sind.
  4. PIP-Kompatibilität. Befehle wie uv pip install arbeiten mit requirements.txt, was die Migration von bestehenden Projekten vereinfacht.

UV-Einrichtung

Der typische Workflow für ein neues wissenschaftliches Python-Projekt sieht folgendermaßen aus:

# Install uv (curl pipe to sh, cross-platform)
curl -LsSf https://astral.sh/uv/install.sh | sh

# Create a project with a specific Python version
uv init my-simulation --python 3.11
cd my-simulation

# Add core scientific dependencies
uv add numpy scipy matplotlib

# Add domain-specific libraries
uv add fipy mpmath

# Add development tools
uv add --group dev pytest ruff ty

# Generate and commit a lockfile
uv lock
git add pyproject.toml uv.lock
git commit -m "Initial project with pinned dependencies"

uv sync wird aus dem Lockfile installiert, um deterministische Reproduktionen zu gewährleisten. Jeder, der das Repository klont und uv sync ausführt, erhält genau die gleichen aufgelösten Versionen.

Die Bytecode-Kompilierungs-Quirk

Hier verhält sich uv anders als PIP und wissenschaftliche Rechnerteams haben unerwartete Wände getroffen.

uv Verschiebt die Bytecode-Kompilierung auf den ersten Lauf. Wenn uv ein Paket installiert, speichert es den vorkompilierten Bytecode in einem Cache, kompiliert jedoch nicht jede Datei sofort. Dadurch werden uv-Installationen etwa 3- bis 4-mal schneller als PIP. Der erste Import einer Bibliothek (insbesondere numpy oder scipy) kann jedoch etwa 2,5-mal langsamer sein als eine von PIP installierte Kopie, da der Bytecode zum Importzeitpunkt kompiliert wird.

Für die interaktive Entwicklung ist diese Verlangsamung normalerweise nicht wahrnehmbar. Für CI-Pipelines, HPC-Job-Skripts oder Produktionsserver, die bei jedem Lauf numpy oder scipy importieren, ist die Quirk wichtig. Der Fix ist einfach: Fügen Sie Ihrem Synchronisierungsbefehl --compile-bytecode hinzu.

Kontext in der realen Welt: Das Datenteam von Plotly hat genau dieses Problem dokumentiert, nachdem es uv in der Produktion übernommen wurde. Ihre Produktionsserver sahen merklich langsamere Importe von Numpy, bis sie die Flagge hinzugefügt hatten. Die vollständige technische Aufschlüsselung finden Sie im Blogbeitrag von Plotly zu UV-Quirks.

Das exklusive Indexverhalten

uv behandelt die Einträge --extra-index-url standardmäßig als exklusiv nach PEP 0708. Wenn ein Paket in Ihrem primären Index vorhanden ist, wird uv niemals den zusätzlichen Index dafür überprüfen. Dies schützt vor Abhängigkeitsattacken – ein böswilliger Akteur kann ein Paket, das auf einem bekannten Index gehostet wird, nicht durch einen kompromittierten Spiegel ersetzen. Es werden jedoch auch vorhandene requirements.txt-Pipelines durchbrochen, die von zusätzlichen Indizes für Fallback-Pakete abhängen.

Wenn Ihr Labor einen privaten Paketindex oder einen conda-kompatiblen Index verwendet, müssen Sie den index-strategy explizit in pyproject.toml konfigurieren. Ohne diese Konfiguration kann uv die Pakete nicht auflösen, die auf dem zusätzlichen Index zu finden ist.

Wenn UV nicht ausreicht

uv verwaltet Python-Pakete und Python-Dolmetscher. Es werden keine Systemabhängigkeiten von Python-Systemen verwaltet: C- und C++-Bibliotheken, Fortran-Compiler, MPI, CUDA-Toolkits, HDF5-, FFTW- oder Grafikbibliotheken.

Für diese Abhängigkeiten bleibt Conda der Standard. Das empfohlene Muster ist die Verwendung von uv für Python-Pakete und Conda (oder Pixi) für Abhängigkeiten auf Systemebene. Viele wissenschaftliche Teams koppeln die beiden Werkzeuge – Conda für den Systemstack, uv für die Python-Ebene.

Wenn es sich bei Ihrem Projekt um Nicht-Python-Abhängigkeiten wie MPI, CUDA oder HDF5 handelt, lesen Sie den zugehörigen Leitfaden zu Verwaltung von Abhängigkeiten in wissenschaftlichem Python , das Conda, Lockfiles und wann jedes Tool verwendet werden soll.

Ruff: Der Linter, der sechs Werkzeuge ersetzt

Ruff ist ein rostbasierter Linter und Formatierer von Astral. Es ersetzt Schwarz (Formatierung), iSort (Import Sorting), Flake8 (Style Checks), Pyupgrade (Entfernung von Dead-Code) und Autoflake (nicht verwendete Variablenentfernung) in einer einzigen Binärdatei, die 10 bis 100 Mal schneller abläuft als der kombinierte alte Stapel.

Das macht es besonders attraktiv für das wissenschaftliche Rechnen, bei dem große Codebasen mit gemischten Python-Versionen und Legacy-Modulen mit den traditionellen Tools einige Sekunden dauern können, bis sie sich verfeinern. Ruff macht es in Millisekunden.

Wissenschaftliche Bibliotheken verwenden bereits Ruff

Ruff ist nicht mehr nur ein Web-Framework-Linter. Wichtige wissenschaftliche Bibliotheken haben es übernommen:

  • Scipy – Das Kernteam der numerischen Methodenbibliothek ist auf Ruff migriert.
  • Pandas – Verwendet Ruff zur Style-Durchsetzung in der gesamten Codebasis.
  • FastAPI und umarmendes Gesicht – beide verwenden Ruff als einzige Formatierer und Linter.

Diese Adoption ist wichtig, da Ruff die kantigen Fälle von wissenschaftlichem Code behandelt – lange DocStrings, komplexe Typanmerkungen, ältere Python-2-Importe – ohne dabei zu verlieren oder Formatierungsfehler einzuführen. Die offizielle Ruff-Dokumentation listet alle drei Bibliotheken als Adopter auf. Die vollständige Liste finden Sie in den offizielle Ruff-Dokumente .

Konfiguration

Ruff konfiguriert vollständig aus pyproject.toml:

[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = ["E", "F", "I", "N", "W", "UP", "RUF"]
ignore = ["E501"]

[tool.ruff.format]
quote-style = "double"

Das Array select gibt an, welche Regelsätze aktiviert werden sollen. E und F decken PEP 8-Fehler und Pyflakes-Prüfungen ab. I behandelt die Importsortierung (Ersetzen von ISORT). N Erzwingt Namenskonventionen. UP führt eine Modernisierung im Pyupgrade-Stil aus. RUF Fügt Ruff-spezifische Regeln hinzu. Die Zeile ignore entfernt E501 (zu langer Linie), da Ruff die Zeilenlänge an den Formatierer delegiert und so den Linter schnell hält.

Migration von Black + Isort + Flake8

Das Entfernen des alten Stapels ist unkompliziert. Nach der Installation von Ruff können Sie die Befehle ersetzen:

# OLD stack
black .
isort .
flake8 .
pyupgrade --py38 src/

# NEW stack
ruff check .
ruff format .

ruff check behandelt alle Stilprüfungen. ruff format behandelt alle Formatierungen. Das sind zwei statt vier Befehle, die eine Binärdatei statt vier separate ausführen.

Der wissenschaftliche Python-Entwicklungsleitfaden empfiehlt ausdrücklich, für Stilprüfungen von Flake8 zu Ruff zu migrieren. Die offizielle Empfehlung finden Sie in ihren Sicherheits- und Entwicklungshandbuch .

Ty: Typenkontrolle ohne Schmerzen

ty ist der im Dezember 2025 veröffentlichte Typ-Checker der nächsten Generation von Astral. Es ersetzt myPy als empfohlenen statischen Typprüfer im Astral-Ökosystem. Es ist in Rost geschrieben und so konzipiert, dass es schnell, strikt und mit nicht kommentiertem Code kompatibel ist.

Der Geschwindigkeitsgewinn

Der dramatischste Vorteil von Ty ist die Geschwindigkeit. In einem realen Benchmark eines Benutzers, der auf einer tatsächlichen wissenschaftlichen Python-Codebasis von mypy zu TY migriert ist, hat mypy 46 Sekunden< gedauert, und TY hat den gleichen Check in 2,19 Sekunden durchgeführt – ungefähr 20 Mal schneller. Siehe den vollständigen Benchmark in der stackademische Migrationspost .

Dies ist wichtig, da die Typprüfung häufig der längste CI-Schritt in einem Python-Workflow ist. Wenn Sie 46 Sekunden auf 2,2 Sekunden verkürzen, verkürzen Sie die CI-Warteschlangenzeiten, können Entwickler schneller Feedback erhalten und eine vollständige Typprüfung in Zweigen ermöglichen, in denen selbst langsame Typenprüfer übersprungen worden wären.

Die schrittweise Garantie

Im Gegensatz zu myPy implementiert TY eine graduale Garantie: Es werden keine Fehler bei Code angezeigt, der keine Anmerkungen enthält. Wenn ein Modul def calculate(x, y): return x + y ohne Typhinweise enthält, behandelt TY es als untypisiert und beschwert sich nicht über fehlende Anmerkungen. Dies ist ideal für die Migration von wissenschaftlichen Codebasen mit teilweise getippten Modulen – ein häufiges Muster im Forschungscode, bei dem die Kernsimulations-Engine getippt wird, Helfer-Skripte und -Notebooks jedoch nicht.

Das offizielle TY-Handbuch erläutert die schrittweise Garantie im Detail. Der entscheidende Punkt ist, dass das Hinzufügen von Typannotationen zu einem Modul nicht dazu führt, dass TY Fehler in diesem Modul meldet – es meldet nur Fehler in bereits getipptem Code. mypy macht das Gegenteil: Es meldet Fehler bei jeder nicht kommentierten Funktion, auf die es trifft, die vorhandene Codebasen bricht, die keine vollständigen Anmerkungen haben.

Spezifikationskonformität: Der Kompromiss

Hier ist der Kompromiss, den Sie verstehen müssen, bevor Sie TY in CI setzen.

Laut einem umfassenden Vergleich von MyPy, Pyright, Ty und Pyre liegt die Python-Typisierungsspezifikation von Ty bei ca. 53 Prozent, während Pyright etwa 98 Prozent erreicht und mypy erreicht ungefähr 58 Prozent. Dies bedeutet, dass TY nur die Hälfte der Typisierungsspezifikationen abdeckt, und es kann Randfälle übersehen, die Pyright erfasst.

Bis Ty Version 1.0 erreicht, ist die empfohlene CI-Strategie ein zweischichtiger Ansatz:

  1. Lokale Entwicklung: Verwenden Sie TY für schnelles Feedback (2-Sekunden-Checks).
  2. CI-Pipelines: Verwenden Sie PyRight für die vollständige Spezifikationsabdeckung (fängt ty Misses).

Dies gibt Ihnen sowohl Geschwindigkeit als auch Richtigkeit. Sobald Ty 1,0 erreicht und seine Spezifikationskonformität verbessert wird, können Sie sich für CI auf TY verlassen.

Konfiguration

Ty konfiguriert ab pyproject.toml:

[tool.typer]
python-version = "3.11"
strict = true

Das Flag strict aktiviert alle strengen Modusprüfungen (implizite Spalte, no-untyped-def usw.). Die vollständige Konfigurationsreferenz finden Sie in das TY-Handbuch.

Migrationshandbuch: Vom alten Stack zum neuen

Hier der praktische Vorher-Nachher-Vergleich. Wenn Sie derzeit PIP, VENV, BLACK, ISort, Flake8 und MYPY verwenden, zeigt diese Tabelle genau, was jedes Werkzeug ersetzt.

Aufgabe Alter Stapel (2023 und früher) Moderner Stapel (2025-2026) Notizen
Paketmanager Pip UV 10-100 × schnellere Installationen, Lockfiles enthalten
Virtuelle Umgebungen Venv / virtualenv In UV eingebaut UV verwaltet Venvs automatisch
Python-Versionsverwaltung pyenv / pyenv-virtualenv In UV eingebaut UV-Downloads Dolmetscher auf Anfrage
Stilfusse Flake8, pydocstyle Halskrause Ruff ersetzt beide in einer Binärdatei
Formatierung Schwarz Ruff (Ruff-Format) Gleiche Ausgabe wie Schwarz in den meisten Fällen
Sortierung importieren iSort Ruff (Ruff-Check –fix) In Ruffs Fusselregeln eingebaut
Typprüfung mypy Ty (lokal), Pyright (CI) Ty ist 20 × schneller; Pyright fängt Ty Misses
Konfiguration 5+ verstreute Konfigurationsdateien single pyproject.toml Alle Tools aus einer Datei gelesen

Schritt-für-Schritt-Migration

Hier ist der konkrete Migrationspfad für ein bestehendes Projekt:

# 1. Install uv and Ruff
uv pip install uv ruff

# 2. Create pyproject.toml (replacing setup.cfg)
cat >> pyproject.toml <<EOF
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.backends._deprecated"

[project]
name = "my-simulation"
version = "0.1.0"
dependencies = [
    "numpy",
    "scipy",
    "fipy",
]
EOF

# 3. Add Ruff config
cat >> pyproject.toml <<EOF

[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = ["E", "F", "I", "N", "W", "UP"]
ignore = ["E501"]
EOF

# 4. Add ty config
cat >> pyproject.toml <<EOF

[tool.typer]
python-version = "3.11"
strict = true
EOF

# 5. Run uv sync to manage dependencies
uv sync

# 6. Run Ruff to check and format existing code
ruff check .
ruff format .

# 7. Run ty locally for fast type feedback
ty check .

Dieser Pfad funktioniert, weil die Ausgabe von Ruff nahezu identisch mit dem Formatierungsstil von Schwarz ist, sodass der formatierte Code bekannt ist. Die allmähliche Garantie von TY bedeutet, dass während der Migration keine nicht kommentierten Module gebrochen werden. Sie können Typanmerkungen inkrementell hinzufügen, ohne befürchten Sie, dass Ty-Oberflächenfehler auf dem Code, den Sie noch nicht eingegeben haben, eingegeben werden.

Wenn Ihr Projekt auf requirements.txt angewiesen ist, beachten Sie, dass uv über uv pip install -r requirements.txt installiert werden kann. Generieren Sie jedoch für eine langfristige Reproduzierbarkeit eine uv.lock-Datei und wechseln Sie von requirements.txt. Weitere Informationen zu Lockfiles und Reproduzierbarkeit finden Sie im zugehörigen Handbuch zu Abhängigkeiten in wissenschaftlichen Python verwalten.

Was wir empfehlen: ein Entscheidungsrahmen

Nicht jedes Team sollte alle drei Werkzeuge gleichzeitig übernehmen. Der richtige Stapel hängt von den Anforderungen Ihres Projekts ab. Verwenden Sie diesen Entscheidungsrahmen, um Folgendes zu wählen:

  1. Benötigen Sie keine Python-Abhängigkeiten? (MPI, CUDA, HDF5, C++-Bibliotheken, Fortran-Compiler)
    • Ja: Verwenden Sie Conda für diese Abhängigkeiten. Sie können neben Conda weiterhin uv für die Python-Pakete verwenden.
    • Nein: Fahren Sie mit der nächsten Frage fort.
  2. Publieren Sie ein Python-Paket für Pypi?
    • Ja: Erwägen Sie Gedichte für ausgereifte Veröffentlichungsworkflows oder uv für schnellere Installationen während der Entwicklung. Beide unterstützen Pypi Publishing.
    • Nein: uv ist die Standardauswahl für neue Forschungsprojekte.
  3. Arbeiten Sie in CI/CD-Pipelines, wo die Installationszeit wichtig ist?
    • Ja: Verwenden Sie uv. Die Geschwindigkeitsgewinne (10-100 × über PIP) verkürzen die CI-Warteschlangenzeiten direkt.
    • Nein: Entweder uv oder Gedichte können je nach Teamkenntnis funktionieren.
  4. Wie wichtig ist die vollständige Abdeckung der Typprüfung in CI?
    • hoch : Verwenden Sie Pyright für CI, TY für die lokale Entwicklung. Dies gibt Ihnen sowohl Geschwindigkeit als auch Richtigkeit.
    • low : Ty allein reicht für die meisten Forschungscodebasen aus.

Für die meisten neuen Forschungsprojekte ist der empfohlene Stack:

  • UV für Paketverwaltung und Lockfiles
  • Ruff zum Fusseln und Formatieren
  • Ty für die lokale Typprüfung (schnelles Feedback)
  • Pyright zur CI-Typprüfung (vollständige Spezifikationsabdeckung)

Diese Kombination gibt Ihnen Geschwindigkeit, Korrektheit und Reproduzierbarkeit – die drei Säulen der Forschungssoftwarequalität.

Einschränkungen: Wann bleiben Sie bei den alten Werkzeugen?

Der moderne Stapel ist leistungsstark, aber kein universeller Ersatz. Hier sollten Sie die alten Werkzeuge behalten:

Conda für Nicht-Python-Abhängigkeiten

UV verwaltet Python-Pakete und Python-Dolmetscher. Es verarbeitet keine kompilierten C-Bibliotheken, Fortran-Compiler, MPI-, CUDA-Toolkits, HDF5-, FFTW- oder Grafikbibliotheken. Für diese bleibt Conda (oder Pixi) der Standard für das wissenschaftliche Rechnen. Viele Teams verwenden Conda für Systemabhängigkeiten und uv für Python-Pakete in derselben Umgebung.

mypy für die vollständige Spezifikationsabdeckung

Bis Ty Version 1.0 erreicht und seine Spezifikations-Konformitätslücke schließt, ist MyPy oder Pyright die sicherere Wahl für CI-Umgebungen, die eine vollständige Typprüfung benötigen. Verwenden Sie ty für die lokale Entwicklung, bei der Geschwindigkeit wichtig ist, und Pyright (oder mypy) für CI, wenn die Richtigkeit wichtig ist.

Poesie für Pypi Publishing

Wenn Sie wissenschaftliche Python-Pakete in Pypi veröffentlichen, verfügt Poetry immer noch über ausgereifte Veröffentlichungsworkflows, Abhängigkeitsgruppen und eine gut dokumentierte Build-Pipeline. uv unterstützt Pypi-Publishing, aber seine Workflows sind neuer und weniger dokumentiert als die Poesie. Wenn Ihr Team etablierte Dokumentationen und lange Produktionsbilanzen schätzt, ist Poesie möglicherweise immer noch die bessere Wahl für die Veröffentlichungsseite Ihres Workflows.

Zusammenfassung und nächste Schritte

Die wissenschaftliche Python-Toolchain ist gereift. Der rostgetriebene Stapel – UV, Ruff und TY – ersetzt die alten fragmentierten Werkzeuge durch etwas schnelleres, einfacheres und besser integriertes. Hier sind die Imbisser:

  1. UV ist der Standard-Paketmanager für neue Projekte. Verwenden Sie --compile-bytecode auf Servern und CI-Pipelines. Verwenden Sie daneben Conda für Nicht-Python-Abhängigkeiten.
  2. RUFF ersetzt Black, iSort, Flake8, Pyupgrade und Autoflake. Scipy und Pandas verwenden es bereits. Konfigurieren Sie alles aus pyproject.toml.
  3. Ty ist der schnellste verfügbare Typ Checker – 20 mal schneller als myPy. Verwenden Sie es lokal. Verwenden Sie Pyright für CI, bis Ty 1,0 erreicht.
  4. pyproject.toml ist die einzige Konfigurationsquelle. Alle drei Werkzeuge lesen daraus. Keine verstreuten Konfigurationsdateien mehr.

Wenn Sie ein neues Simulationsprojekt starten, übernehmen Sie vom ersten Tag an den modernen Stapel. Wenn Sie ein vorhandenes Projekt migrieren, folgen Sie dem Schritt-für-Schritt-Pfad oben – die Formatierungsausgabe von Ruff ist nahezu identisch mit der von Black, und die schrittweise Garantie von TY bedeutet, dass Sie den vorhandenen Code während des Übergangs nicht brechen.

Weitere Informationen zum wissenschaftlichen Python-Bibliotheksstapel finden Sie im Scientific Python Ecosystem Guide, der numpy, scipy, sympy, matplotlib abdeckt, Jupyter und Scikit-Learn. Eine tiefere Abdeckung des Abhängigkeitsmanagements und der Lockfiles finden Sie in der Anleitung Verwalten von Abhängigkeiten in der wissenschaftlichen Python-Anleitung. Lesen Sie die Best Practices für die Wartung, die gut mit der modernen Toolchain übereinstimmen, die Best Practices für die Aufrechterhaltung des wissenschaftlichen Codes.

Das wissenschaftliche Python-Ökosystem geht nirgendwo hin. Die Art und Weise, wie Sie damit arbeiten, hat sich geändert, und die Übernahme des modernen Stacks bietet Ihnen schnellere Builds, eine einfachere Konfiguration und eine bessere Reproduzierbarkeit – alles ohne die Bibliotheken zu ändern, die Sie für die Berechnung verwenden.

Referenzen und Weiterlesen