Быстрее, выше, сильнее: сравнение подходов poetry, rye и uv

Привет, с вами снова Егор, Tech Lead компании ИдаПроджект. Я все еще занимаюсь стратегией, процессами и командами в направлении backend-разработки 🙂

Когда-то давно (по меркам IT), шесть лет назад, мы сходили на конференцию и послушали про poetry, преисполнились и внедрили его у себя на проектах. Но ничто не стоит на месте: вот уже два года мир знает о uv, а недавно появился еще и rye. Поэтому я посвятил пару выходных тестированию этих инструментов, чтобы использовать на наших типичных проектах.

В этой статье сравним poetry, uv и rye: кто быстрее управляет зависимостями, как использовать их в Docker, и какой выбрать в 2025 году. Заодно пробежимся по философии инструментов и посмотрим пару новых PEP стандартов, которые могут улучшить работу с зависимостями.

Что такое rye и его философия

В текущей реализации (на момент написания статьи актуальная версия 0.43.0) rye — это экспериментальное решение для сборки и управления локальными проектами. К нему стоит относиться как к попытке привести python-разработку к единому стандарту сборки. Кроме того, rye замахивается на внедрение единого стандарта форматирования кода, линтинг и вообще — переизобретение стандарта PEP 8.

В релизной форме rye хочет стать прослойкой, через которую будет идти вся разработка под python.

Чтобы понять, для чего создали rye, и какие проблемы хотели решить с его помощью, почитайте документ о его философии. Автор rye, Armin Ronacher (создал и поддерживает проекты Pallets, куда входит, например, всем известный Flask) рассказывает о сложностях в разработке и ссылается на язык rust и его инструменты (rustup и cargo) как на цель, к которой должна стремиться python-разработка.

Общие цели проекта можно свести к следующим пунктам:

Сделать единый механизм получения и установки интерпретатора python для разработки и эксплуатации. Это формат реализации стандарта PEP 771.
Использовать строгие правила по управлению зависимостями и прийти к semver как к стандарту.
Кеширование метаданных пакетов для оптимизаций сборки приложения.
Сделать стандарт Lockfiles (сейчас уже есть драфт PEP 751) и ускорить процесс разрешения зависимостей. Сейчас под капотом используется uv.
Стандартизировать использование virtualenv.
Стандартизировать использование внешних инструментов и инструментария во время разработки.

Планы действительно впечатляющее, но пока посмотрим, как rye «ляжет» на наш стандартный проект, и оценим, насколько удобнее работать с ним, а не с poetry (сейчас он используется у нас в компании по стандарту).

Однако я не буду затрагивать базовое использование rye, почитайте об этом в обзорной статье.

Что такое poetry и какие проблемы он решил в 2019

До Poetry управление зависимостями в Python было болью. Конфликты версий, ручная правка requirements.txt — знакомо? Poetry это изменил.

Pyproject.toml стал центром проекта, где описаны все зависимости. poetry.lock фиксировал версии всех пакетов, включая подзависимости. Больше не нужно гадать с версиями и вручную перебирать их для сборки проекта. Poetry дал надежный способ управлять зависимостями и гарантировать воспроизводимость сборок. Requirements.txt ушел на второй план для управления проектами, уступив место современному подходу с lock-файлами.

Появилось «центральное окно управления проектом» в виде pyproject.toml, где определяются не только зависимости проекта, но и dev-инструментарий, дополнительные скрипты для сборки, параметры линтинга и форматирования кода. Poetry сам автоматически создает нужные виртуальные окружения, что позволило в некоторых кейсах перейти из Docker-контейнеров обратно в разработку с использованием автоматически генерируемых virtualenv окружений. Также это позволило упростить подключение интерпретатора к IDE без костылей: через создание стандартного виртуального окружения в папке проекта. IDE могут автоматически обнаруживать и использовать это окружение, что упрощает настройку интерпретатора и отладчика. Это контрастирует с ситуацией, когда виртуальные окружения создавались «как попало», или вообще использовался системный интерпретатор, что влекло за собой проблемы с настройкой IDE и переходом между проектами.

Если кратко, то poetry дал понять, что можно многое поменять и сделать проще, если стандартизировать все аспекты локальной разработки через единый интерфейс.

И какой же poetry в 2025?

Сейчас poetry представляет собой инструментарий для полноценной работы с проектом и закрывает почти все потребности маленьких и средних команд. В текущих экспериментальных релизах poetry добавилось управление установкой python, и улучшилась производительность фиксирования зависимостей.

Наш типичный проект с Poetry, и как он собирается в Docker

Для базового примера возьмем маленький проект — с минимальным количеством нужных зависимостей.

[tool.poetry.dependencies]  # core  python = "3.12.*"  Django = "4.2.*"  psycopg2-binary = "2.9.*"  django-redis = "5.4.*"  gunicorn = "^20.1.0"  # Models \ Admin  phonenumbers = "^8.12.29"  django-phonenumber-field = "5.2.*"  # Rest  djangorestframework = "3.14.*"  drf-spectacular = "0.24.*"  django-filter = "22.*"  # Test  factory-boy = "^3.2.0"  pytest = "^6.2.4"  pytest-mock = "^3.6.1"  pytest-cov = "^2.12.1"  pytest-django = "^4.4.0"  pytest-sugar = "^0.9.4"  # Others  Pillow = "10.0.1"  [poetry.group.dev.dependencies]  django-debug-toolbar = "^3.2.1"  # linting  ruff = "0.0.*"  # Typehinting  mypy = "1.*"  mypy-extensions = "1.*"  django-stubs = "1.14.*"  djangorestframework-stubs="1.8.*"

Сборка проекта тоже довольно простая и без излишеств:

 FROM python:3.12-alpine  # Set environment variables  ENV PYTHONUNBUFFERED 1  ENV PYTHONWARNINGS ignore  ENV CURL_CA_BUNDLE ""  ENV POETRY_VIRTUALENVS_CREATE true  ENV PATH "${PATH}:/root/.local/bin"  # Expose port 8000  EXPOSE 8000/tcp  # Set the working directory for the application  WORKDIR /app  # Copy just the dependencies installation from the current directory to the Docker image  COPY pyproject.toml poetry.lock /app/  # Install necessary dependencies  RUN set -ex; \     apk update; \     apk add --no-cache --virtual build-deps \         curl \         git \         gcc \     && rm -rf /var/lib/apt/lists/* \     && pip install --no-cache-dir --user poetry==2.1.0 \     && poetry install --no-interaction --no-ansi \     && pip install  --no-cache-dir --user requests \     && apk del --no-cache build-deps  # Create link python interpritator  RUN ln -sf $(poetry env info -e) /python  # Copy wait-for script and give it necessary permissions  COPY wait-for /usr/bin/  RUN chmod +x /usr/bin/wait-for  # Copy the current directory contents into the container  COPY . /app/  # Give necessary permissions to entrypoint  RUN chmod +x entrypoint.*

Поскольку целью статьи является сравнение подхода к работе poetry, rue и uv, мы сознательно не будем оптимизировать сборку в Docker-файлах и размер образов.

Метрики по сборке: скорость и потребление ресурсов

Для замера скорости сборки немного модифицируем Dockerfile и добавим вот такие строки:

# Install necessary dependencies  RUN set -ex; \     apk update; \     apk add --no-cache --virtual build-deps \         curl \         git \         gcc \     && rm -rf /var/lib/apt/lists/* \     && pip install --no-cache-dir --user poetry==2.1.0  RUN time -v poetry lock # Фиксирование зависимостей  RUN time -v poetry install --no-interaction --no-ansi --all-groups # Установка зависимостей  RUN pip install  --no-cache-dir --user requests \     && apk del --no-cache build-deps

С помощью команды docker compose -f docker-compose.yml build backend_poetry --no-cache --progress plain запустим сборку. Опция --progress plain нужна, чтобы выводить все логи сборки.

Фиксирование зависимостей заняло 10 секунд.

#9 [backend_poetry  5/12] RUN time -v poetry lock  #9 0.944 Creating virtualenv uv,_poetry_compare-9TtSrW0h-py3.12 in /root/.cache/pypoetry/virtualenvs  #9 1.449 Resolving dependencies...  #9 10.29    Command being timed: "poetry lock"  #9 10.29    User time (seconds): 2.63  #9 10.29    System time (seconds): 0.95  #9 10.29    Percent of CPU this job got: 36%  #9 10.29    Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 9.95s  #9 10.29    Average shared text size (kbytes): 0  #9 10.29    Average unshared data size (kbytes): 0  #9 10.29    Average stack size (kbytes): 0  #9 10.29    Average total size (kbytes): 0  #9 10.29    Maximum resident set size (kbytes): 88424  #9 10.29    Average resident set size (kbytes): 0  #9 10.29    Major (requiring I/O) page faults: 0  #9 10.29    Minor (reclaiming a frame) page faults: 138441  #9 10.29    Voluntary context switches: 388  #9 10.29    Involuntary context switches: 138  #9 10.29    Swaps: 0  #9 10.29    File system inputs: 24  #9 10.29    File system outputs: 55896  #9 10.29    Socket messages sent: 0  #9 10.29    Socket messages received: 0  #9 10.29    Signals delivered: 0  #9 10.29    Page size (bytes): 4096  #9 10.29    Exit status: 0  #9 DONE 10.3s

По трейсу можно понять, что пиковая доля нагрузки CPU заняла бы 36%, при этом памяти было использовано 88 мегабайт. Это, конечно, немного, но скорость в 10 секунд удручает.

А вот установка зависимостей с помощью poetry происходит за пять секунд. По CPU уходило в 100%, так как по факту происходила распаковка скачанных зависимостей. По памяти вышло 88 мегабайт.

#10 [backend_poetry  6/12] RUN time poetry install --no-interaction --no-ansi --all-groups  …  #10 4.846   Command being timed: "poetry install --no-interaction --no-ansi --all-groups"  #10 4.846   User time (seconds): 2.48  #10 4.846   System time (seconds): 2.03  #10 4.846   Percent of CPU this job got: 100%  #10 4.846   Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 4.48s  #10 4.846   Average shared text size (kbytes): 0  #10 4.846   Average unshared data size (kbytes): 0  #10 4.846   Average stack size (kbytes): 0  #10 4.846   Average total size (kbytes): 0  #10 4.846   Maximum resident set size (kbytes): 88844  #10 4.846   Average resident set size (kbytes): 0  #10 4.846   Major (requiring I/O) page faults: 0  #10 4.846   Minor (reclaiming a frame) page faults: 166516  #10 4.846   Voluntary context switches: 45109  #10 4.846   Involuntary context switches: 229  #10 4.846   Swaps: 0  #10 4.846   File system inputs: 0  #10 4.846   File system outputs: 359408  #10 4.846   Socket messages sent: 0  #10 4.846   Socket messages received: 0  #10 4.846   Signals delivered: 0  #10 4.846   Page size (bytes): 4096  #10 4.846   Exit status: 0  #10 DONE 5.0s

Переведем проект для использования uv

Для этого нужно создать новый файл pyproject.toml и заново внести в него все зависимости. Я просто добавил все нужные зависимости через CLI с помощью uv add; получился следующий файл:

[project]  name = "uv_poetry_compare"  version = "0.1.0"  requires-python = ">=3.12"  dependencies = [     "django==4.2",     "django-debug-toolbar==3.2.1",     "django-filter==22.*",     "django-phonenumber-field==5.2.*",     "django-redis==5.4.*",     "djangorestframework==3.14.*",     "drf-spectacular==0.24.*",     "factory-boy==3.2.0",     "gunicorn==20.1.0",     "phonenumbers==8.12.29",     "pillow==10.0.1",     "psycopg2-binary==2.9.*",     "pytest==6.2.4",     "pytest-cov==2.12.1",     "pytest-django==4.4.0",     "pytest-mock==3.6.1",     "pytest-sugar==0.9.4",  ]  [dependency-groups]  lint = [     "django-stubs==1.14.*",     "djangorestframework-stubs==1.8.*",     "mypy==1.*",     "mypy-extensions==1.*",     "ruff>=0.9.10",  ]

Немного поменяем Docker-файл для замера скорости сборки и установки зависимостей:

FROM python:3.12-alpine  COPY --from=ghcr.io/astral-sh/uv:0.6.5 /uv /uvx /bin/  # Set environment variables  ENV PYTHONUNBUFFERED 1  ENV PYTHONWARNINGS ignore  ENV CURL_CA_BUNDLE ""  ENV POETRY_VIRTUALENVS_CREATE true  ENV PATH "${PATH}:/root/.local/bin"  # Expose port 8000  EXPOSE 8000/tcp  # Set the working directory for the application  WORKDIR /app  # Copy just the dependencies installation from the current directory to the Docker image  COPY . /app/  RUN time -v uv lock  RUN time -v uv sync  # Copy wait-for script and give it necessary permissions  COPY wait-for /usr/bin/  RUN chmod +x /usr/bin/wait-for  # Give necessary permissions to entrypoint  RUN chmod +x entrypoint.*

Для идеального результата воспользуйтесь советами из официальной документации по формированию Dockerfile для продакшен-среды и для локальной разработки.

Метрики по сборке

Сейчас объясню пару нюансов работы uv.

Формирование uv.lock файла происходит за 4,8 секунды. CPU в пике собрало 50%, а памяти было использовано примерно 73 МБ. По факту скорость — по сравнению с poetry — увеличилась в два раза.

В итоге по формированию uv.lock файла вышли следующие метрики:

#11 [backend_uv stage-0 5/6] RUN time -v uv lock  #11 5.287 Resolved 57 packages in 4.81s  #11 5.300   Command being timed: "uv lock"  #11 5.300   User time (seconds): 1.64  #11 5.300   System time (seconds): 0.91  #11 5.300   Percent of CPU this job got: 50%  #11 5.300   Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 5.08s  #11 5.300   Average shared text size (kbytes): 0  #11 5.300   Average unshared data size (kbytes): 0  #11 5.300   Average stack size (kbytes): 0  #11 5.300   Average total size (kbytes): 0  #11 5.300   Maximum resident set size (kbytes): 73684  #11 5.300   Average resident set size (kbytes): 0  #11 5.300   Major (requiring I/O) page faults: 5  #11 5.300   Minor (reclaiming a frame) page faults: 173258  #11 5.300   Voluntary context switches: 3829  #11 5.300   Involuntary context switches: 175  #11 5.300   Swaps: 0  #11 5.300   File system inputs: 592  #11 5.300   File system outputs: 59472  #11 5.300   Socket messages sent: 0  #11 5.300   Socket messages received: 0  #11 5.300   Signals delivered: 0  #11 5.300   Page size (bytes): 4096  #11 5.300   Exit status: 0  #11 DONE 5.3s

А вот с установкой зависимостей все куда интереснее, поскольку если мы cделаем обычный sync, то по трейсу увидим, что все установилось за 0.6 секунд — что, конечно, неправда.

#12 [backend_uv stage-0 6/6] RUN time -v uv sync  #12 0.260 Resolved 57 packages in 0.62ms  #12 0.399 Uninstalled 15 packages in 136ms  #12 0.399  - certifi==2025.1.31  #12 0.399  - charset-normalizer==3.4.1  #12 0.399  - django-stubs==1.14.0  #12 0.399  - django-stubs-ext==5.1.3  #12 0.399  - djangorestframework-stubs==1.8.0  #12 0.399  - idna==3.10  #12 0.399  - mypy==1.15.0  #12 0.399  - mypy-extensions==1.0.0  #12 0.399  - requests==2.32.3  #12 0.399  - ruff==0.9.10  #12 0.399  - tomli==2.2.1  #12 0.399  - types-pytz==2025.1.0.20250204  #12 0.399  - types-pyyaml==6.0.12.20241230  #12 0.399  - types-requests==2.32.0.20250306  #12 0.399  - urllib3==2.3.0  #12 0.402   Command being timed: "uv sync"  #12 0.402   User time (seconds): 0.01  #12 0.402   System time (seconds): 0.13  #12 0.402   Percent of CPU this job got: 96%  #12 0.402   Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 0.15s  #12 0.402   Average shared text size (kbytes): 0  #12 0.402   Average unshared data size (kbytes): 0  #12 0.402   Average stack size (kbytes): 0  #12 0.402   Average total size (kbytes): 0  #12 0.402   Maximum resident set size (kbytes): 25984  #12 0.402   Average resident set size (kbytes): 0  #12 0.402   Major (requiring I/O) page faults: 0  #12 0.402   Minor (reclaiming a frame) page faults: 1777  #12 0.402   Voluntary context switches: 62  #12 0.402   Involuntary context switches: 12  #12 0.402   Swaps: 0  #12 0.402   File system inputs: 40  #12 0.402   File system outputs: 0  #12 0.402   Socket messages sent: 0  #12 0.402   Socket messages received: 0  #12 0.402   Signals delivered: 0  #12 0.402   Page size (bytes): 4096  #12 0.402   Exit status: 0  #12 DONE 0.4s

Поясню ситуацию, почему цифры врут. Uv так устроен, что очень много использует кэши разного уровня (более подробно о них можно почитать тут). Для более релевантного замера нужно добавить параметры -n —reinstall к uv sync, чтобы понять реальное время установки пакетов.

/app # time -v uv sync -n --reinstall  Resolved 58 packages in 0.74ms    Built pytest-sugar==0.9.4  Prepared 40 packages in 2.82s  Uninstalled 40 packages in 427ms  ░░░░░░░░░░░░░░░░░░░░ [0/40] Installing wheels...                                                                                                                                                                                                                                                           warning: Failed to hardlink files; falling back to full copy. This may lead to degraded performance.       If the cache and target directories are on different filesystems, hardlinking may not be supported.       If this is intentional, set export UV_LINK_MODE=copy or use --link-mode=copy to suppress this warning.  Installed 40 packages in 313ms      Command being timed: "uv sync -n --reinstall"      User time (seconds): 1.13      System time (seconds): 2.86      Percent of CPU this job got: 99%      Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 4.00s      Average shared text size (kbytes): 0      Average unshared data size (kbytes): 0      Average stack size (kbytes): 0      Average total size (kbytes): 0      Maximum resident set size (kbytes): 59764      Average resident set size (kbytes): 0      Major (requiring I/O) page faults: 0      Minor (reclaiming a frame) page faults: 127023      Voluntary context switches: 31795      Involuntary context switches: 870      Swaps: 0      File system inputs: 0      File system outputs: 446232      Socket messages sent: 0      Socket messages received: 0      Signals delivered: 0      Page size (bytes): 4096      Exit status: 0

Здесь цифры уже ближе к реальности. Установка заняла четыре секунды и 100% CPU (60МБ оперативной памяти). Это чуть быстрее и оптимальнее, чем poetry, но в установке сложно выиграть время, ведь тут просто скачиваются и распаковываются архивы. Однако если делать тесты «на горячую», то есть используя стандартные кэши, то выигрыш будет весомее (как в первом примере с uv sync).

Отличие lock файла в poetry и в uv

Сразу скажу — серьезных отличий между uv.lock и poetry.lock нет, поскольку они придерживаются структуры, которая описана в PEP 751. Это позволяет быстро добавить поддержку для анализаторов кода и проверок на безопасность, например, в trivy.

И напоследок rye…

…но его мы тестировать не будем. Почему? А потому что uv встроен в rye, и сборка проекта происходит на базе uv, так что смысла в этом нет. Как было сказано выше, rye, в первую очередь, инструмент для локальной разработки, который позволяет обойтись без docker.

Но мы посмотрим насколько удобно переносить сборку проекта под rye. Для этого надо адаптировать pyproject.toml.

[tool.rye]  universal = true  virtual = true

Затем запустим команду rye sync. Это вызовет uv и сгенерирует два файла requirements.lock и requirements-dev.lock, после чего будут установлены зависимости в virtualenv в папке .venv.

Dockerfile теперь выглядит так:

 FROM python:3.12-alpine  COPY --from=ghcr.io/astral-sh/uv:0.6.5 /uv /uvx /bin/  # Set environment variables  ENV PYTHONUNBUFFERED 1  ENV PYTHONWARNINGS ignore  ENV CURL_CA_BUNDLE ""  ENV POETRY_VIRTUALENVS_CREATE true  ENV PATH "${PATH}:/root/.local/bin"  # Expose port 8000  EXPOSE 8000/tcp  # Set the working directory for the application  WORKDIR /app  # Copy just the dependencies installation from the current directory to the Docker image  COPY . /app/  RUN time -v uv pip install --no-cache --system -r requirements.lock  # Copy wait-for script and give it necessary permissions  COPY wait-for /usr/bin/  RUN chmod +x /usr/bin/wait-for  # Give necessary permissions to entrypoint  RUN chmod +x entrypoint.*

Установка зависимостей в моем случае прошла за 7.4 секунды. В целом, ничего особенного.

#11 [backend_rye stage-0 5/8] RUN time -v uv pip install --no-cache --system -r requirements.lock  …  #11 7.276   Command being timed: "uv pip install --no-cache --system -r requirements.lock"  #11 7.276   User time (seconds): 2.03  #11 7.276   System time (seconds): 2.68  #11 7.276   Percent of CPU this job got: 66%  #11 7.276   Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 7.04s  #11 7.276   Average shared text size (kbytes): 0  #11 7.276   Average unshared data size (kbytes): 0  #11 7.276   Average stack size (kbytes): 0  #11 7.276   Average total size (kbytes): 0  #11 7.276   Maximum resident set size (kbytes): 74864  #11 7.276   Average resident set size (kbytes): 0  #11 7.276   Major (requiring I/O) page faults: 185  #11 7.276   Minor (reclaiming a frame) page faults: 247591  #11 7.276   Voluntary context switches: 33758  #11 7.276   Involuntary context switches: 313  #11 7.276   Swaps: 0  #11 7.276   File system inputs: 30312  #11 7.276   File system outputs: 259792  #11 7.276   Socket messages sent: 0  #11 7.276   Socket messages received: 0  #11 7.276   Signals delivered: 0  #11 7.276   Page size (bytes): 4096  #11 7.276   Exit status: 0  #11 DONE 7.4s

Заключение

Сравнение инструментов Poetry, uv и rye показало активное развитие экосистемы управления зависимостями в Python. Poetry все еще сохраняет позицию зрелого и многофункционального инструмента, закрывающего большинство потребностей разработчиков. В то же время uv предлагает существенное ускорение операций с зависимостями, подтвержденное тестами скорости фиксации и установки. Rye, интегрируя uv, стремится к созданию единого стандарта разработки, но его практическое применение требует чуть иного подхода, нежели в poetry и uv.

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

Весь код можно глянуть в этом репозитории.

Ну а на этом всё, если что хотите добавить или рассказать свое видение — заходите в комментарии 🙂

ссылка на оригинал статьи https://habr.com/ru/articles/894552/