Как стать автором
Обновить

Комментарии 26

Пушка и бомба? Создание окружения быстрее - замечательно, но оно создаётся не каждый месяц. Что такое работа с версиями - не проникся, активируешь окружение нужного Питона, а его всё равно нужно активировать, и всё. И ради этого допускать в свою жизнь ещё одну сущность?

Нет, это хорошо для Rust и даже может быть кому-то полезно, но те же bat или nnn, тоже плоды движения ржавых переписчиков, играют на две лиги выше.

Спасибо за вопросы!
Данный проект интересен своей разнонаправленностью. По сути в нем 3 инструмента. Менеджер пакетов, менеджер окружения и версий интерпретаторов. Как минимум тут убираются 2 сущности venv и pyenv.
Согласен, окружение и Python мы не ставим каждый день, но разница в скорости загрузки библиотек значительная и это можно применить в тех же пайплайнах в CI.
Возможно есть подобные проекты еще. Если подскажите какие буду только благодарен) Про nnn спасибо! Посмотрю)
Целью данной статьи был обзор конкретно данного решения. И я выделил те плюсы и минусы, которые есть у данного решения.
Про работу с версиями я имел ввиду установку нескольких версий интерпретаторов в систему. pyenv и аналогичные решения позволяют мягко установить разные версии без повреждения зависимостей в основной системе.

Пушка и бомба? Создание окружения быстрее - замечательно, но оно создаётся не каждый месяц. Что такое работа с версиями - не проникся, активируешь окружение нужного Питона, а его всё равно нужно активировать, и всё. И ради этого допускать в свою жизнь ещё одну сущность?

Ну, кстати говоря, это на своём ноутбуке вы не каждый месяц создаёте.

А представьте себе билд-сервер, который, например, строит десятки Docker-образов приложений каждый день. Даже на 10 секунд быстрее - это меньше ресурсов сервера, которые могут достаться другой задаче.

Еще, как пример, ограничение на процессорное время сервера в github Actions - 2000 мин в месяц (тариф github Free), которое по большей части тратится на сборку окружений для запуска тестов. Используя более быстрые пакетные менеджеры/инструменты виртуализации можно кратно увеличить количество запускаемых тестов, не привысив установленные лимиты.

И все десятки приложений на питоне и у всех десятков приложений разные версии библиотек и разные окружения, и ни один образ нельзя создать на основе другого? И на этом гипотетическом сервере ещё не реализовали ни один альтернативный метод оптимизации, всё тупо через pip из интернета качается? Тогда да, будет полезно, особенно если ошибка в работе с новым инструментом с которой придётся несколько часов разбираться не аннулирует выигрыш из-за ускорения за несколько месяцев.

Когда вам доведется поработать в достаточно крупной компании - вы перестанете смеяться в цирке и задавать такие вопросы.

Небольшой коллектив из 600 человек может разрабатывать 300+ различных сервисов для одного продукта, причём, да, разных версий, втч экспериментальных. Одни сервисы могут требовать определённые версии других, втч и старых. Билд-сервер загружен постоянно и не уверен что он был один.

Не очень большая часть из этого была на питоне, но, тем не менее, ситуация более чем реальна. Конечно, одной заменой менеджера пакетов проблемы не решаются, но это один из шагов.

Хорошо, что экосистема развивается и появляются новые инструменты.

Так nnn же на C.

Вообще интересно знать почему такая существенна разница во времени?

И как это связано с использованием раста.

Разрешение зависимостей - вычислительно сложная задача. Python упирается в свою же производительность.

Думал он, например, на си, но оказалось действительно на питоне. Казалось бы, могли бы сразу на си реализовать, но мы имеем то, что имеем

В те времена никого не волновала скорость работы пакетного менеджера, в разумных пределах. Это стало важно когда пошли CI с их постоянными пересборками.

Выглядит как заявка на то, чтобы сделать всё остальное устаревшим. В экосистеме Python как раз не хватало консистентности.

Тут до сих пор не могут от setup.py избавиться, в итоге просто резолвинг зависимостей в общем случае требует выполнять произвольные скрипты, которые могут ещё и не запуститься. А чтобы заменить всё на один пакетный менеджер и систему сборки...ну, мечтать конечно приятно и не вредно...

Не иронично ли, что создатель Flask использовал Django для Sentry? Интересный парень, этот Армин.

Некрокоммент, но Sentry основана в 2011, а "интересный парень" Армин в компании работает с 2015. Всё ещё иронично? :)

Очень часто большую часть времени в установке зависимостей занимает сборка какого-нибудь пакета из исходников, потому что нет готового бинарника под нужную архитектуру. А ту скорость, про которую написано в статье, вы будете ощущать только при установке окружения начисто с нуля, что происходит... ну пару раз за несколько месяцев? может... Так что самый большой плюс получают наверное те, кто постоянно устанавливает что-то и желательно с нуля.

Зато есть жирный минус, перекрывающий сомнительный "самый огромный" плюс - Платформозависимые lockfile. То есть, я либо использую для разработки и деплоя одну платформу, либо виртуализация, эмуляция и и иже с ними. Хотя даже питон сам по себе платформонезависимый, и собрать можно практически под любую архитектуру, и разрабатывать и запускатьь код в большинстве случаев без шаманства на разных архитектурах.

Так что я прям даже не знаю, я лучше заюзаю pdm или poetry. Не так быстро ставят, зато экономят время на разработку в целом без пляски с архитектурами.

Соглашусь, если вы используете poetry, то стоит взвесить все за и против. Но если например проект только начался или уже используется pip, то можно смело рассматривать вариант UV. Переход будет несложным, а удобство прибавится в проекте.

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 , чтобы в виртуальное окружение подтянулось?

В примере я указал путь до скачанного интерпретатора. Но если у Вас уже стоит Python нужной версии, то можно указать и uv venv -p python3.12 venv.

Спасибо за обзор!

Кажется, что не упомянуты следующие важные вещи: автор 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). То есть если она сработала сегодня, то сработает и завтра и без лишних скачиваний.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории