uv dedupliziert jetzt jede Datei im Wheel-Cache und spart so 545 MiB
uv: Deduplicate all files in the wheel cache
Ein Pull Request für uv, den schnellen Python-Paketmanager von Astral, führt Datei-Deduplizierung im Wheel-Cache ein. Bisher wurde nur auf Wheel-Ebene dedupliziert; jetzt werden alle Dateien anhand ihres BLAKE3-Hashes gespeichert und per Hardlink in die Archive verlinkt. Das spart auf einer typischen Maschine 545 MiB (ca. 10 % des Caches). Kalte Installationen werden dadurch um weniger als 4 % langsamer, warme Installationen bleiben unverändert. Die Änderung ist hinter dem Preview-Feature content-addressed-cache verfügbar.
Wir sparen also 545,2 MiB auf meinem lokalen Rechner, also etwa 10 % des Caches – und der Nettoeffekt scheint ein <4 % langsamerer Kaltstart zu sein, was ich hier für wahrscheinlich lohnenswert halte.
- notatallshaw
Als pip-Maintainer habe ich mir schon lange die Kompromisse von uvs Cache angesehen; es ist der größte Faktor, der warme Installationen bei uv im Vergleich zu pip schneller macht. Da pip die ursprünglichen Distributionen cached und sie jedes Mal entpacken muss, cached uv die entpackte Distribution und verlinkt sie hart, wenn möglich.
Aber es gab schon immer zwei große Probleme:
1. Keine Möglichkeit, exakte Distributionen für einen "Download"-Befehl zu reproduzieren (es gibt kein uv-Äquivalent zu "pip download")
2. Für Leute mit vielen verschiedenen Umgebungen wächst der Cache deutlich stärker als bei pip
Ich bin gespannt zu sehen, zumindest anekdotisch, ob dies Punkt 2 deutlich verbessert; dann könnten wir vielleicht eine zweischichtige Caching-Strategie ohne die erheblichen Speicherkosten umsetzen.
- mark_l_watson
Schöne Verbesserung. Für mich ist uv das "Quicklisp für Python". uv lässt mich Python einfach genießen, so wie Quicklisp Common Lisp angenehmer macht.
Ich war schon immer ein Lisp-Anhänger, aber vor ein paar Jahren, als ich anfing, uv zu nutzen, begann ich Python als eine Sprache zu sehen, die ich wirklich genießen kann, also investierte ich Mühe, um meine Python-Entwicklungsumgebung nahezu reibungslos zu gestalten.
- stephenlf
uv ist das Rückgrat jeder modernen Python-Bibliothek. Ich freue mich über die Verbesserungen.
- CivBase
Eine 10%ige Reduzierung der Cache-Größe gegen eine 4%ige Verlangsamung erscheint mir nicht offensichtlich lohnenswert, besonders wenn sie mit einer erhöhten Komplexität einhergeht.
- TacticalCoder
> Deduplizierung auf Dateiebene: Jede Datei wird nun unter ihrem BLAKE3-Hash gespeichert
Blake3 ist wirklich ein wunderbar schneller kryptografischer Hash. Ich verwende ihn für mein eigenes "Deduplizierungs-/Integritäts-/Berserker"-Dienstprogramm (das ich gemacht habe, bevor LLMs ein Ding waren).
Wenn ich eine Datei namens:
DSC98731-b3-7b39197a22.JPG
habe, dann:
- wenn diese Datei nicht auf 7b39197a22 zurückprüft, liegt ein Dateiintegritätsproblem vor (erstaunlich, und es hat mir bereits geholfen, Probleme zu beheben)
- wenn irgendeine andere Datei denselben Blake3-Hash 7b39197a22 hat, ist es ein Duplikat
- wenn dieser 7b39197a22-Checksumme in meiner Datenbank ist, "können Dinge passieren".
Zum Beispiel kann meine DB sagen: "Jede Datei mit einem Blake3-Hash von 7b39197a22 kann immer gelöscht werden" oder "Jede Datei mit einem Blake3-Hash von 887463c09e, die einen generischen Dateinamen wie "dscXXXXX" hat, kann immer in "20260722jackJohnAtTheBeach-b3-778463c09e.jpg" umbenannt werden" (oder was auch immer dir passt).
Es ist wirklich großartig (und ich weiß, dass mehrere hier unabhängig ähnliche Schemata gemacht haben), und Blake3 ist ein erstaunlicher Hash für solche Anwendungen.