uv 0.12.13 перевіряє хеші PEP 658 і швидше розв’язує залежності без повних wheel
Оновлення Python-менеджера пакетів посилює перевірку metadata, додає GraalPy 3.13 і зменшує зайві завантаження під час resolution.

Python-менеджер проєктів uv отримав версію 0.12.13 із двома змінами навколо цілісності та швидкості package resolution. Інструмент почав перевіряти хеші окремих metadata-файлів PEP 658 і навчився повторно використовувати відомі хеші з fragment прямого URL, щоб не завантажувати цілий wheel лише заради резолюції.

PEP 658: metadata окремо від wheel
PEP 658 дозволяє package index публікувати metadata distribution як окремий файл. Resolver може прочитати назву, версію та залежності, не завантажуючи повний wheel. Це особливо відчутно для великих пакетів і для CI, де чисте середовище створюється багато разів.
У 0.12.13 uv звіряє хеш, коли завантажує такий metadata sidecar. Перевірка закриває важливу прогалину: оптимізація не повинна послаблювати контроль цілісності лише тому, що клієнт отримує скорочений артефакт замість wheel. Якщо index повертає JSON, uv також віддає перевагу сучасному полю core-metadata над його legacy-синонімами.
Менше повних завантажень під час resolution
Для залежностей із прямими URL хеш часто записують у fragment адреси. Коли metadata доступна окремо, uv тепер повторно використовує підтримуваний хеш із цього fragment і уникає повного завантаження wheel на етапі розв’язання. Це не скасовує отримання самого пакета під час інсталяції, але скорочує попередню роботу resolver та мережевий трафік.
Виграш залежить від структури проєкту, cache hit rate і поведінки package index. Якщо metadata sidecar немає або тип хешу не підтримується, інструмент мусить застосувати інший шлях. Тому реліз не слід подавати як універсальне прискорення кожної команди.
GraalPy 3.13 і Windows Nano Server
До керованих реалізацій Python додано GraalPy 3.13.0. Це розширює сценарії тестування застосунків на альтернативному runtime, але сумісність native extensions і конкретних пакетів усе одно потрібно перевіряти окремо. Наявність інтерпретатора у каталозі uv не гарантує, що весь стек CPython-залежностей запрацює без змін.
На Windows ресурси entry-point launcher тепер редагуються в пам’яті. Зміна потрібна для сумісності з Nano Server і має зменшити конфлікти з антивірусними перевірками. Для контейнерів Windows це прибирає залежність від файлових операцій, які доступні не в кожному мінімальному образі.
Preview: exclusions у virtual workspace
Експериментальна команда uv check враховує exclusions інструмента ty, коли автоматично вибирає учасників virtual workspace. Це має прибрати ситуації, де перевірка заходить у свідомо виключений пакет. Оскільки функція preview, її поведінка ще може змінюватися, а production CI краще фіксувати версію uv.
Практичний план оновлення
- Зафіксувати 0.12.13 у CI та порівняти час resolution на холодному кеші.
- Перевірити приватний package index на коректні
core-metadataі хеші PEP 658. - Для прямих URL зберегти контрольовані хеші та протестувати відтворювану інсталяцію.
- На Windows Nano Server прогнати створення entry points і запуск установлених console scripts.
Релізні артефакти мають GitHub Artifact Attestations, а команда публікує контрольні суми. Це допомагає перевірити походження binary, але не замінює lock-файл, pinning джерел і перевірку хешів залежностей самого проєкту.
Висновок: uv 0.12.13 — невелике, але практичне оновлення supply-chain шляху. Воно поєднує швидший доступ до metadata з явнішою перевіркою цілісності й заслуговує на планове тестування в Python CI.
Матеріал перекладено, переказано та доповнено редакцією українською мовою.
Читайте далі — ми вже розбираємо наступну важливу тему.


