Comments 25
Пушка и бомба? Создание окружения быстрее - замечательно, но оно создаётся не каждый месяц. Что такое работа с версиями - не проникся, активируешь окружение нужного Питона, а его всё равно нужно активировать, и всё. И ради этого допускать в свою жизнь ещё одну сущность?
Нет, это хорошо для Rust и даже может быть кому-то полезно, но те же bat или nnn, тоже плоды движения ржавых переписчиков, играют на две лиги выше.
Спасибо за вопросы!
Данный проект интересен своей разнонаправленностью. По сути в нем 3 инструмента. Менеджер пакетов, менеджер окружения и версий интерпретаторов. Как минимум тут убираются 2 сущности venv и pyenv.
Согласен, окружение и Python мы не ставим каждый день, но разница в скорости загрузки библиотек значительная и это можно применить в тех же пайплайнах в CI.
Возможно есть подобные проекты еще. Если подскажите какие буду только благодарен) Про nnn спасибо! Посмотрю)
Целью данной статьи был обзор конкретно данного решения. И я выделил те плюсы и минусы, которые есть у данного решения.
Про работу с версиями я имел ввиду установку нескольких версий интерпретаторов в систему. pyenv и аналогичные решения позволяют мягко установить разные версии без повреждения зависимостей в основной системе.
Пушка и бомба? Создание окружения быстрее - замечательно, но оно создаётся не каждый месяц. Что такое работа с версиями - не проникся, активируешь окружение нужного Питона, а его всё равно нужно активировать, и всё. И ради этого допускать в свою жизнь ещё одну сущность?
Ну, кстати говоря, это на своём ноутбуке вы не каждый месяц создаёте.
А представьте себе билд-сервер, который, например, строит десятки Docker-образов приложений каждый день. Даже на 10 секунд быстрее - это меньше ресурсов сервера, которые могут достаться другой задаче.
Еще, как пример, ограничение на процессорное время сервера в github Actions - 2000 мин в месяц (тариф github Free), которое по большей части тратится на сборку окружений для запуска тестов. Используя более быстрые пакетные менеджеры/инструменты виртуализации можно кратно увеличить количество запускаемых тестов, не привысив установленные лимиты.
И все десятки приложений на питоне и у всех десятков приложений разные версии библиотек и разные окружения, и ни один образ нельзя создать на основе другого? И на этом гипотетическом сервере ещё не реализовали ни один альтернативный метод оптимизации, всё тупо через pip из интернета качается? Тогда да, будет полезно, особенно если ошибка в работе с новым инструментом с которой придётся несколько часов разбираться не аннулирует выигрыш из-за ускорения за несколько месяцев.
Когда вам доведется поработать в достаточно крупной компании - вы перестанете смеяться в цирке и задавать такие вопросы.
Небольшой коллектив из 600 человек может разрабатывать 300+ различных сервисов для одного продукта, причём, да, разных версий, втч экспериментальных. Одни сервисы могут требовать определённые версии других, втч и старых. Билд-сервер загружен постоянно и не уверен что он был один.
Не очень большая часть из этого была на питоне, но, тем не менее, ситуация более чем реальна. Конечно, одной заменой менеджера пакетов проблемы не решаются, но это один из шагов.
Хорошо, что экосистема развивается и появляются новые инструменты.
Так nnn же на C.
Вообще интересно знать почему такая существенна разница во времени?
Выглядит как заявка на то, чтобы сделать всё остальное устаревшим. В экосистеме Python как раз не хватало консистентности.
Дополню что есть ещё rye от Армина Ронахера (создатель Flask и Sentry), оно под капотом использует этот uv или pip-tools, приятный инструмент для менеджмента питонячьего зоопарка
Очень часто большую часть времени в установке зависимостей занимает сборка какого-нибудь пакета из исходников, потому что нет готового бинарника под нужную архитектуру. А ту скорость, про которую написано в статье, вы будете ощущать только при установке окружения начисто с нуля, что происходит... ну пару раз за несколько месяцев? может... Так что самый большой плюс получают наверное те, кто постоянно устанавливает что-то и желательно с нуля.
Зато есть жирный минус, перекрывающий сомнительный "самый огромный" плюс - Платформозависимые lockfile. То есть, я либо использую для разработки и деплоя одну платформу, либо виртуализация, эмуляция и и иже с ними. Хотя даже питон сам по себе платформонезависимый, и собрать можно практически под любую архитектуру, и разрабатывать и запускатьь код в большинстве случаев без шаманства на разных архитектурах.
Так что я прям даже не знаю, я лучше заюзаю pdm или poetry. Не так быстро ставят, зато экономят время на разработку в целом без пляски с архитектурами.
3) Создаем окружение с новой версией
uv venv -p /home/timur/.local/share/uv/python/cpython-3.12.3-linux-x86_64-gnu/bin/python3 venv2
Не очень-то удобно выглядит. В том же pdm это делается через `pdm venv create 3.12`, ну или через `pdm init` и дальнейшем выбором версии.
С pyproject.toml никак не взаимодействует? Например, те же зависимости и настройка? Имеется ли возможность указать ему на файл .env , чтобы в виртуальное окружение подтянулось?
Спасибо за обзор!
Кажется, что не упомянуты следующие важные вещи: автор Hatch пишет "UV is under active development and may not work for all dependencies". Источник: https://hatch.pypa.io/latest/how-to/environment/select-installer/#enabling-uv
Также в репозитории uv в ридми авторы пишут следующее: "uv does not yet have a stable API; once uv's API is stable (v1.0.0), the versioning scheme will adhere to Semantic Versioning". Источник: https://github.com/astral-sh/uv.
Инструмент видимо находится в активной и экспериментальной фазе разработки (кажется, поэтому в Hatch предусмотрена возможность отключения uv), но выглядит интересно и многообещающе)
В нет есть фича которая хорошо ускоряет установку больших пакетов, если вы не используете полный lock всех зависимостей.
However, uv's resolution strategy can be configured to support alternative workflows. With --resolution=lowest, uv will install the lowest compatible versions for all dependencies, both direct and transitive.
Наприерм зависимость написанна other-lib>=1.5
Частая проблема пипа, это то, что скачивается последняя версия (например 3.14), и она не подходит по зависимостям. Тогда скачивается версия постарше. И так может продолжаться долго, до 90% всего времени устрановки.
С этой опцией всё начинается снизу, со самой старой версии (1.5). То есть если она сработала сегодня, то сработает и завтра и без лишних скачиваний.
Дерево уже есть - uv pip tree.
UV. Обзор пакетного менеджера Python